service accounts: Phase 1 — backend CRUD and API key token exchange

[GregorShear]

Summary

• Adds internal.service_accounts and internal.api_keys tables for non-human identities that authenticate via API keys and are authorized through the existing user_grants / role_grants system
• Implements GraphQL mutations (createServiceAccount, disableServiceAccount, enableServiceAccount, createApiKey, revokeApiKey) and a paginated serviceAccounts query, all gated on admin capability of the service account's prefix
• Adds a new POST /api/v1/auth/token REST endpoint that exchanges either a flow_sa_-prefixed API key or a refresh token for a short-lived access token, selected by the grant_type field
• Also exposes refresh-token management over GraphQL (refreshTokens query, createRefreshToken / deleteRefreshToken mutations), self-scoped to the authenticated user

Key design decisions

• Service accounts are auth.users rows. All existing RLS policies, PostgREST authorization, user_roles() resolution, and role_grants traversal work unchanged. This avoids putting the PostgREST→GraphQL migration on the critical path.
• One user_grants row per service account. Created from the SA's stored prefix/capability. Disabling deletes the grant and all API keys; re-enabling restores the grant (but not the keys — new ones must be minted).
• API keys are verified and exchanged entirely in the application layer, not via generate_access_token. The flow_sa_-prefixed key encodes base64(key_id:secret); the endpoint decodes it, verifies the secret against a bcrypt hash using SQL crypt() (no Rust bcrypt dependency), checks expiry and disabled_at, then mints a 1-hour authenticated JWT directly. The flow_sa_ prefix routes the request and avoids collisions with refresh-token inputs.
• API keys use fixed expiry (valid_for ISO-8601 duration → now() + interval), not the sliding window used by refresh tokens.
• generate_access_token is unchanged. The refresh-token branch of /api/v1/auth/token calls the existing generate_access_token(refresh_token_id, secret) and passes its JSON result through. Existing callers are unaffected.

Test plan

• Create service account → create API key → exchange for access token via /api/v1/auth/token
• Authorization checks (Bob can't manage or list Alice's service accounts)
• Revoke API key → exchange fails
• Disable service account → API keys deleted, grant removed, exchange fails, new key creation blocked
• Re-enable service account → grant restored, new keys can be created, exchange works
• Idempotency guards (disable-while-disabled and enable-while-enabled both error)
• List query scoped to the caller's admin prefixes

[GregorShear]

not related to this PR but helping me not commit a file related to a parallel workstream...