Revocation gap: drop_user does not invalidate previously-issued session cookies / bearer tokens

## Summary

When a user is removed via `drop_user`, credentials **previously issued to that user** can continue to authenticate until they expire:

- **Session cookies** (`enableSessions`) and **bearer / operation (JWT) tokens** keep working for a removed user — the session/token validation path does not fully fail closed when the underlying user record no longer exists.
- **HTTP Basic auth is unaffected** — it re-validates on each request and correctly rejects a removed user immediately.

## Impact

This is a **revocation gap**, not something reachable by an unauthenticated party — it only affects a principal who *already held* a valid credential. But it means `drop_user` does not promptly cut off that user's existing sessions/tokens:

- An offboarded / de-authorized user retains access via their existing session cookie or token until it expires.
- The default session-cookie lifetime is effectively unbounded (a very far-future `Expires`), so "until it expires" can be indefinite for cookies.
- Because the session resolves by **username**, if a username is later reused for a *new* account, a previously-issued session can resolve against the new account.
- Matters for offboarding, incident response, and compliance ("we removed the user, but they still had access").

Role changes to a **live** user do propagate correctly/synchronously; this issue is specifically about a **removed** user's already-issued cookie/token credentials.

## Scope

- Affected: session-cookie auth, bearer/operation-token auth.
- Not affected: HTTP Basic auth (revokes immediately).
- Not reachable pre-auth (requires a previously-valid credential for the affected user).

## Suggested direction

- Fail closed when the resolved user no longer exists (don't authenticate a placeholder identity).
- Have `drop_user` invalidate the removed user's active sessions.
- Consider a per-user session generation/epoch and a finite default session-cookie TTL.

_Detailed reproduction, affected code paths, and specifics are recorded in the private Security Notes for this issue (kept out of the public description per security-handling practice)._

Start with the session-cookie and bearer/operation-token validation paths and the drop_user flow; the public issue does not name specific files or tests. Confirm the behavior against the private Security Notes, then ensure removed users' existing credentials fail closed while HTTP Basic auth and live-user role changes remain unaffected.

Written by the indexing model from the issue text.