fix(audit-2026-06-11/revocation-lag): evict PrincipalCache on credential change

The PrincipalCache (token-hash -> resolved Principal, 60s TTL) had no
eviction hook, so deactivation / password change / API-key revocation
flipped the DB rows but the cache kept serving the stale principal for
up to the TTL window. Closes the audit's PrincipalCache revocation-lag
Medium and greens authz::deactivating_user_revokes_their_api_keys.

- PrincipalCache::evict_user(user_id) + evict_token(hash).
- One shared cache Arc threaded into AuthState / AdminsState /
  ApiKeysState (a per-state cache would let the middleware's own copy
  keep authenticating a revoked principal).
- Evict on: deactivation, password change (both evict_user), logout
  (evict_token, precise), single API-key delete (evict_user).
- H-E1 note: DB-write invalidation stays best-effort by design (a blip
  must not undo the rotation); the cache evict is what makes it take
  effect on the next request.
- Renamed bearer_and_cookie_produce_same_principal ->
  session_token_and_api_key_produce_same_principal (cookie auth was
  removed in C-1; the test never tested cookies).

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

crates/manager-core/src/api_keys_api.rs

@@ -39,6 +39,10 @@ const NAME_MAX: usize = 64;
 #[derive(Clone)]
 pub struct ApiKeysState {
     pub keys: Arc<dyn ApiKeyRepository>,
+    /// Audit 2026-06-11 (PrincipalCache revocation-lag) — evicted when
+    /// a user deletes one of their own keys so it stops authenticating
+    /// from cache immediately rather than after the cache TTL.
+    pub principal_cache: Arc<crate::auth_middleware::PrincipalCache>,
 }
 
 pub fn api_keys_router(state: ApiKeysState) -> Router {
@@ -160,6 +164,12 @@ async fn delete_key(
         // we deliberately don't leak the distinction.
         return Err(ApiKeysError::NotFound(id));
     }
+    // Audit 2026-06-11 (PrincipalCache revocation-lag) — the cache is
+    // keyed by token hash, which we can't derive from the key id, so
+    // evict every cached principal for this user. That also drops their
+    // session entries; re-auth on the next request is the right cost for
+    // a deliberate key revocation.
+    state.principal_cache.evict_user(principal.user_id);
     Ok(StatusCode::NO_CONTENT)
 }