[shuv1337]

Post-cutover backlog, item (d): list a connection's keys and revoke one, without revoking the connection.

Rotating a 90-day seat key on the connection page meant revoking the whole connection. That killed the seat's current key too, and today it also burns the connection ID (see the separate ID-reuse fix). The account-wide Tokens page already lists connection keys with their own Revoke button. This PR puts the same control where operators manage the connection.

API (hosted)

• GET /api/organizations/:org/mcp-connections/:connection/keys returns, newest first, each key's id, name, start (its first characters), createdAt, expiresAt and lastRequest. It never returns key material.
• POST /api/organizations/:org/mcp-connections/:connection/keys/:key/revoke deletes that one key.
• Who can call them: the same rules as minting. Only the connection's owner; admins and owners can call them with an API key, but only for their own connections.
• Refusals: another user's connection, or a revoked one, returns 404 ConnectionNotFound. A key that isn't bound to that connection returns 404 ConnectionKeyNotFound, which is new.
• Implementation: both are server-only Better Auth endpoints. The connection must be standing and owned by the caller, and the key's metadata must bind it to that connection. Each revocation writes an audit line. Bearer checks read the key row, so a revoked key fails immediately while the connection and its other keys stay.

UI

The connection page gets a Connection keys section showing each key's name, first characters, created, expires and last used, with a per-key Revoke and a confirm dialog. Creating a key refreshes the list.

Tests

New connectionKeyRevoke scenario in connection-keys.spec.ts:

• two keys are listed without secrets, and another connection lists none of them;
• an admin and the owner each get 404 on someone else's connection;
• the key itself gets 403 on these routes;
• after revoking one key, it gets 401 and fails over MCP, while the other key and the connection keep working, and a second revoke returns 404;
• the dashboard revoke works.

With the server-side delete removed, the scenario fails as it should. On self-host, the 9 related scenarios pass (connection-keys, connection-api-keys, mcp-connections), and bun run check passes.

connection-keys.spec.ts
connection-api-keys.spec.ts
mcp-connections.spec.ts