per-user api keys, resolved at both identity doors

a user can mint a long-lived key for an app or a device instead of
carrying a 30-day session, so multiple logins on the mobile apps are
per-device revocable rather than one shared token.

identity was being decided independently in userMiddleware and
originScopeMiddleware, each verifying the token itself. teaching only
one of them a new credential format is how those two stop agreeing, so
both now call resolveAuthToken and neither knows what a bearer string
is. verified: a member's key returns the same status as their jwt on
every route tried, 403s included.

a key carries its holder's full authority — not an escalation, it
equals what the password could already do. scoping wants a scopes
column, not a change here.

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

src/servers/capabilities/registry.ts

@@ -86,9 +86,13 @@ export const CAPABILITIES: Capability[] = [
   {
     key: 'account',
     label: 'Account',
-    description: 'Sign in, your own profile, password and preferences',
+    description: 'Sign in, your own profile, password, preferences and API keys',
     kind: 'core',
-    api: ['/user', '/dock'],
+    // `/api-keys` is core rather than app or admin because a key is not new authority — it is a second way
+    // to present the authority the account already has, so denying it would only force the holder to keep
+    // using a password in places a password should not go. What a key can then DO is decided by the same
+    // capability checks as any other request from that user; nothing here widens them.
+    api: ['/user', '/dock', '/api-keys'],
     routes: ['/settings/profile'],
   },
   {