#3123 Accept usernames for user subjects in grant files

Problem

A user subject in a grant file names the OAuth user id, for example user:. A reader cannot tell who an entry is for without a comment beside each id. This was the nice-to-have in swamp-club#3070, which shipped the subjects list (PR 2894) and left usernames out as a separate design question.

Example of what operators want to write:

grants:
  - subjects: [user:alice, user:bob]
    effect: allow
    actions: [read, run]
    resource: workflow:*

Why this needs design, not a parser change

Grants match the principal, and a user principal is keyed by its OAuth subject (sub). A username can be renamed, and after an account is deleted the name can be registered by someone else. A grant matched on the username at request time would then quietly apply to a different person, which for an allow grant is a privilege escalation and for a deny grant a silent loss of the deny.

Precedent to follow

src/serve/oauth_access_list_resolution.ts already resolves the usernames in auth.admins and auth.allowed-users to subs at serve startup, caches the result in the oauth-resolved-admins vault entry, keeps a resolved sub when the provider later reports the name not found, and never re-checks a name first seen missing, so a typo cannot be claimed by someone who registers that name later. Grant file usernames should get the same guarantees: resolve once to a sub, pin it, and never re-point a pinned name.

Questions to settle

• Syntax: reuse user: and decide per value whether it is a username or a sub, or add an explicit form (for example a separate kind) so a value is never ambiguous. A username that looks like a sub, or a sub that matches someone's username, must not be guessable.
• When to resolve: at serve startup and on swamp access reload, alongside grant file parsing. What happens when the provider is unreachable, and for a name that does not resolve: reject the file, skip the entry, or keep the last pinned sub.
• Where the pin lives, and how the reconciler identity (entryIdentityKey) treats it, so a rename does not revoke and recreate grants.
• How swamp access grant list, swamp access check and the audit actor show these grants (username, sub, or both).
• Which OAuth providers can resolve usernames; providers without a lookup need a clear error rather than silently never matching.

Out of scope

Changing how principals are identified at request time. Matching stays on the sub; only the file syntax gains a way to name it.