feat: mint access tokens with the negotiated scope - #28237

Assert the issued access token against the live API rather than only
against the api_keys row: coder:workspaces.access reads a template and is
refused the deletion. Drive every name the scope catalog offers through
the conversion so a name added to the catalog but not the api_key_scope
enum fails here instead of leaving a client holding an unredeemable code.
Refresh a token row seeded the way migration 000569 leaves a pre-existing
grant to confirm the backfilled coder:all still means unrestricted.

Document the scope parameter, the registration-time allowlist, and the
two limitations that remain: only Dynamic Client Registration can declare
an allowlist, and a scope parameter on refresh is ignored.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

RFC 6749 §5.1 makes the scope parameter REQUIRED in the token response
whenever the granted scope differs from what the client requested. Neither
grant sets it, so a client whose request was narrowed against the app's
allowlist, or whose empty request was defaulted to the allowlist or to the
unrestricted sentinel, cannot tell what authority the token it just received
actually carries. It finds out as an unexplained 403 later.

Both grants already hold the value: the authorization code path writes
dbCode.Scope onto the refresh row, and the refresh path carries dbToken.Scope
onto its replacement.

The sentinel called the scope "unstorable", but storing it is exactly what
already happened; what fails is minting a key from it. Rename it to
errUnmintableScope and drop "stored" from the message it puts on the wire.

Its doc described only the enum-outside branch even though the empty branch
returns it too. Both that doc and the test comment justified the empty case
with the CHECK (scope <> '') constraint, which does not reject the
whitespace-only input the test exercises. Justify it by the writers instead,
which is what actually holds.

Format the offending name with '%s' rather than %q. RFC 6749 section 5.2
limits error_description to %x20-21 / %x23-5B / %x5D-7E, which excludes the
double quote %q emits, and this value reaches the client through that field.

State what the refresh path does with the scope rather than narrating what
it used to do without it.

…Query

authorizeCode rebuilt authorizeQuery's body so it could keep the PKCE
verifier the exchange redeems the code with. Call authorizeQuery and override
the challenge instead, which is the extension point its doc already names, so
the authorize query shape lives in one place.

EveryCatalogNameMintable drove ExternalScopeNames, which returns canonical
names only. The aliases IsExternalScope also accepts, "all" and
"application_connect", are not api_key_scope members and so never reached the
conversion the subtest exists to guard. Drive them too, spelled through
CanonicalScopeName the way authorization spells them before persisting, and
assert each name in the loop is one IsExternalScope accepts.

The Limitations bullet listed the refreshed token keeping its original scope
as a limitation, which RFC 6749 section 6 mandates and the Scopes section
already states as expected behavior. State only the part that is limited:
the client cannot narrow on refresh.

…-negotiated-scope

The authorize comment and the integration guide both still said the
negotiated scope was recorded but not enforced. This PR mints the API
key with it, so that is no longer true. Also document the invalid_scope
the token endpoint now returns when a stored scope cannot be minted.

The handler returns codersdk.OAuth2TokenResponse, but the annotation
said oauth2.Token, so the API reference showed no scope field on the
endpoint this PR starts filling it for.