Enforce API token revocation on the auth path

[martsokha]

Summary

Fixes a security gap surfaced while investigating the deferred API-token identity question: revoking a token didn't actually revoke it.

The bearer credential is a self-contained, signed JWT — there is no separate opaque secret, and the JWT's jti claim is the account_api_tokens row id. The auth path (AuthState::from_unverified_header) validated the signature, exp, and account status, but never re-checked the backing token row. So DELETE /api-tokens/{id}/ soft-deleted the row and the management UI stopped listing it, yet the JWT kept authenticating until its exp — up to a year. A leaked or compromised token could not be killed.

Fix

• New query account_api_token_is_active(token_id, account_id) — a cheap SELECT exists(…) scoped to the token's account, returning false once the row is soft-deleted.
• New auth step verify_token_active runs on every authenticated request (alongside the existing account-status and privilege-consistency checks), rejecting a revoked token with 401.

Revocation is now immediate (no cache, so no staleness window — the right default for a security control). It costs one indexed PK lookup per request, on top of the account lookup already performed.

Verification

• Full gate green: check / clippy -D warnings / nightly fmt / test --all-features (13 suites).
• Live E2E: create token → use (200) → DELETE (204) → reuse (401, was 200 before) → caller's other session still works (200). Confirmed jti == returned token id.

Note on the identity question (no code change)

The investigation also resolves the parked "should the token id be a hash?" decision: keep the UUID. The id is load-bearing — it's the JWT jti, the management-endpoint address, and (now) the revocation join key — but never human-facing. A hash/short-id would add no value and would break jti == id symmetry.

🤖 Generated with Claude Code