feat(token): add RFC 8693 token-exchange grant for provider access tokens

[spydon]

What

Adds an RFC 8693 token-exchange grant to POST /token so a client can sign in with a provider-issued access token instead of an OIDC id token:

POST /token?grant_type=urn:ietf:params:oauth:grant-type:token-exchange
{
  "provider": "facebook",
  "subject_token": "<facebook access token>",
  "subject_token_type": "urn:ietf:params:oauth:token-type:access_token"
}

Why

Native Facebook login on Android (supabase/supabase-flutter#1287) only mints an OIDC id token (which carries email/email_verified) on the first authorization. Every subsequent login returns a classic access token with no profile claims and no id token, so the id_token grant is unusable for the common repeat-login case. This is a Facebook platform limitation (Limited Login is iOS-only). See facebook/facebook-android-sdk#1132.

The split, matching how Firebase and Auth0 handle Facebook:

• Signup / first login → OIDC id token via the existing id_token grant (has the email claims).
• Repeat logins → this token-exchange grant.

How

• grant_type is the standard RFC 8693 URN; the provider-specific bit is the subject_token_type + provider (matched case-insensitively), so new providers opt in rather than needing a new grant (the design the reviewer asked for; happy to fold provider into subject_token_type if preferred).
• Verification is provider-specific via a new provider.AccessTokenVerifier interface. Facebook's implementation calls /debug_token (app token sent as a Bearer header, not in the URL; transport errors have the URL stripped so the token can't leak), and requires is_valid, an app_id matching this app, and a USER token type. It returns the token's user_id as the subject.
• Sign-in-existing only: debug_token returns no profile claims, so the grant looks up the existing auth.identities row (provider, provider_id=user_id) and issues a session. It does not create accounts (a brand-new user signs up via the id-token first-login path), and rejects banned users and unconfirmed users (unless AllowUnverifiedEmailSignIns is set), matching the other sign-in paths. A missing identity returns a clear error; the client fallback for that edge case is signInWithOAuth (web). All sign-in failures return a generic Invalid subject_token to avoid account enumeration.

Tests

internal/api/token_exchange_test.go: sign-in of an existing identity, case-insensitive provider, no-identity rejected, banned user rejected, unconfirmed user rejected, unconfirmed allowed when AllowUnverifiedEmailSignIns is set, token from another app rejected, invalid token, non-user token, missing subject_token / provider, unsupported subject_token_type, unsupported provider, disabled provider. All pass against Postgres.

Notes / follow-ups

• Single client-id (intentional): VerifyAccessToken verifies against the primary configured Facebook client id only. Multiple client ids per project are out of scope for this grant (single-app is the expected config); the id_token grant's multi-id handling is unaffected.
• Session-info tokens: Facebook's attenuated, no-user-data token can be added later as another subject_token_type for defense in depth once the client can produce one; the server flow is identical.
• link_identity support is stacked in feat(token): support link_identity in the token-exchange grant #2614.