Story: Give a person's token the permissions they hold

Make a person's token carry the permissions they hold, and stop the token check from passing an empty list. Then a handler's has_permission means what it says for a person as well as for a service.

• Login, party selection, party switching and refresh issue tokens that carry the account's effective permissions, read from the database.
• A change to an account's roles reaches its next token, so a revoked permission stops working within one access lifetime.
• has_permission refuses a token with an empty permission list.
• Each role (SuperAdmin, TenantAdmin, an ordinary member) is walked through its journeys against the running deployment, and every refusal it meets is one it should meet.
• Every new behaviour is proved by a test.

What each role a person can hold grants, and what the BFF answered each role when the walk signed in as it and called the same routes, on 2026-10-03 after tokens carry their permissions and an empty list refuses. The grants come from projects/ores.sql/populate/iam/iam_roles_populate.sql; the walk is evidence/walk_roles.py and its raw output evidence/walk_roles.out. Every walk account except the two administrators works in Acme's top operational party. Service roles are left out: they belong to service accounts, not people.

1. Every person's token carries their permissions. Login with one party, party selection, party switching and refresh read the account's effective permission codes from the database and put them in the token. Refresh reads them again rather than copying the old token's, so a role change reaches the token at the next refresh. The token that only lets a person choose a party carries none. It needs none: the party selection handler checks no permission and accepts only that token's select_party_only audience. Refresh refuses that audience, so it cannot be renewed into a full token. No signer or verifier sets an audience, so a service's request context accepts such a token as an ordinary tenant-scoped one; refusing that audience there belongs with refusing an empty list. The tenant session keeps what it carries now: the administrator's read codes, read from the database when the tenant is entered.
2. The codes are carried as granted, wildcards included. * and x::* stay as they are, so a token holds at most a handful of codes: the largest seeded role grants 17.
3. A role change takes effect within one access lifetime. With the default of 1800 s, a revoked permission stops working within 30 minutes. The maximum session of 28800 s does not lengthen this, because every refresh reads the permissions again. Pushing the change to live sessions is out of scope; the in-process event that announces a change has no listener outside the service.
4. One rule matches a permission. The token check understands * and x::*; the database check authorization_service::check_permission understands only *, so a role granted refdata::* passes one and fails the other. Both use one matching function that understands both.
5. An empty list refuses; no token trusts, by name. The request context's permissions become optional. A context built from a token carries the token's list, and an empty list refuses every check. A context that carries no list passes, as it does now. Only context_factory::make_context, the one place a service builds its base context, produces one, and narrowing a context to a tenant or a party keeps the list it had, so a request's context never becomes trusted for want of one. The request path never reaches a trusted context in production, because every domain service builds a verifier and so validates a token, and it refuses the select_party_only audience by name.
6. Order. Issue tokens with their permissions first, then refuse an empty list, then walk each role. A token issued before the change carries an empty list; its next refresh reads the permissions, so nobody is locked out longer than one access lifetime.

Captured 2026-09-30 in the product backlog; promoted preserving the UUID.

All tasks done.