Sessions survive administrator deletion and password changes — no revocation mechanism

[ChrisonSimtian]

Description

A signed-in session survives the administrator account being deleted, recreated, or having its password
changed. There is no way to revoke access short of waiting out the 14-day cookie lifetime.

Observed accidentally: after dropping and recreating the demo database (so AdminAccounts was empty, then
seeded with a different admin), an existing browser session was still authenticated — the nav rendered
signed-in links and /settings was reachable.

This is a gap in the auth design from #48, not an unlucky edge case. The cookie carries the username and
role as claims, and nothing re-checks them against the store on subsequent requests, so the cookie is the
authority for its whole lifetime.

The root cause is a deliberate decision made in #48 that turns out to have been too narrow: we took ASP.NET
Core Identity's PasswordHasher but not the rest of Identity, including the security stamp — the
mechanism whose entire purpose is invalidating existing sessions when credentials change. Skipping the user
store was right; skipping the revocation mechanism was not, and nothing replaced it.

Impact

• Deleting the administrator does not sign anyone out.
• Changing the password does not invalidate other sessions (so a stolen cookie survives the usual response
  to a suspected compromise).
• No way to force-sign-out a session at all.

Severity is moderate rather than high for a single-admin self-hosted tool on a trusted network — but
"change the password" is the reflex when someone suspects a leak, and here it does nothing to existing
sessions, which is worse than the user will assume.

Reproduction Steps

1. Set up an administrator and sign in.
2. Delete the row: delete from "AdminAccounts";
3. Reload any authenticated page — still signed in, still authorised.
4. Same holds after recreating a different administrator, or changing the password.

Expected Behavior

Deleting the administrator, or changing its password, invalidates existing sessions promptly.

Actual Behavior

Sessions remain valid for the full 14-day cookie lifetime regardless.

Scope

• Add a security stamp to AdminAccount — a value that changes whenever credentials change.
• Validate it per request via cookie authentication's OnValidatePrincipal event: load the account,
  compare the stamp against the one in the cookie, and reject the principal on mismatch or if the
  account is gone. Use ValidateInterval so this is a periodic check rather than a database read on
  every single request.
• Roll the stamp on password change and on administrator deletion.
• Tests: a session is rejected after the account is deleted; after the password changes; and a valid
  session is unaffected.

Alternative

Shorten ExpireTimeSpan so a stale session dies sooner. That reduces the window without fixing anything,
and trades it against forcing the operator to log in constantly.

Notes

• Belongs with Pluggable authentication: an auth port with a simple built-in provider (standalone) and OIDC as the real target #48 (authentication). Filed separately so the gap is not lost inside a closed PR discussion.
• Worth revisiting alongside it whether OIDC needs equivalent handling — there, revocation is largely the
  identity provider's concern, but our cookie lifetime still applies locally.