fix(events): re-validate live socket keys against the database

[rmyndharis]

A WebSocket socket carries the API key as it stood when it connected and never refreshes that snapshot, while the rooms it joined are never revisited. Only the node that processes a revoke, delete or narrowing tears the key's sockets down, so on any other node the key keeps receiving events it is no longer authorized for until the client resubscribes or disconnects. The session.qr gate rests on the same snapshot, refreshed only at subscribe time. Even on a single node the snapshot can go stale for good: a socket whose key was revoked between its validation and its registration in the gateway is not there when the eviction runs, and nothing looks at it again.

• EventsGateway.sweepExpiredApiKeys becomes sweepApiKeyAuthorization on the same 60 s timer: the expiry each socket already carries is settled first and without the database, so an unreachable or locked table cannot keep an expired key streaming; then one batched read (AuthService.findAuthorizationStates) of the distinct key ids currently holding sockets, and eviction through the existing path with the reason that applies, so the client-facing frame is unchanged in shape and names the cause: row gone (deleted), inactive (revoked), past its expiry (expired), or role / allowedIps / allowedSessions / expiry no longer matching the socket's snapshot (authorization_changed).
• New src/modules/auth/api-key-authorization.ts holds the authorization fingerprint (role, both allowlists normalized and sorted, expiry) plus the scope-list normalizer moved out of AuthService. The immediate eviction in AuthService.update now compares the same fingerprint, so the two paths cannot disagree, and the columns the usage tracker rewrites (lastUsedAt, usageCount, updatedAt) are outside it by construction.
• handleSubscribe returns without joining any room when the socket was evicted while its re-validation was in flight, instead of registering rooms in the adapter after the disconnect. The connect-time snapshot is still deliberately not refreshed there, with the reason stated in the code; what the subscribe does record is that the fresh key no longer matched that snapshot, because the rooms (and the QR gate) it grants outlive the row that granted them. A widening put back before the next tick would otherwise leave the socket holding every session's rooms with nothing left for the sweep to compare.
• Docs: the WebSocket authorization model in docs/06 §6.5 (including the QR note), the cross-replica scope in docs/13 and the replica warning in docs/10.

Behaviour: an operator-driven key change still evicts immediately and synchronously in the same request, with no new dependency, no Redis requirement and no new environment variable. What changes is that a client can now also be disconnected with an UNAUTHORIZED frame up to a minute after a change this process never saw, and should reconnect and resubscribe. Redis propagation of evictions is deliberately out of scope here; the timer is the convergence mechanism.

Verified with a spec that drives the real AuthService, ApiKeyUsageTracker and a real better-sqlite3 api_keys table, since a stub cannot prove the fingerprint does not evict every socket on each tick: usage-only writes and a rename or reordered allowlist evict nobody; deletion, revocation, expiry and narrowing each evict with their own message; the connect-while-revoking race is evicted; a resubscribe under a narrowed key does not launder the snapshot; a socket that subscribed under a widening is evicted after the row is put back; an expired key's sockets are evicted with the table unreadable; an eviction during a subscribe joins no room; the operator path still evicts synchronously. Each behaviour was mutation-checked by reverting the line and confirming the failure. The CI gate set was run locally.

Fixes #1625