Add authenticated session listing and revocation APIs, track the auth provider on sessions, and expose active session controls in account security settings.
After /auth/refresh, Postgres got the new access + refresh nonces but
the Redis cached session still held the OLD ones. The next request:
1. Frontend uses the new access token (new access_nonce in JWT)
2. Backend ValidateAccessToken → GetSession → hits Redis cache
3. Cached session has the OLD access_nonce
4. session.AccessNonce != t.Nonce → ErrToken (401)
5. Frontend tries to refresh with the new refresh token
6. RefreshToken → GetSession → again hits stale Redis
7. sess.RefreshNonce (old) != t.Nonce (new) → ErrToken
8. Frontend clears tokens and bounces to /auth/login
The access token's 10-minute TTL was the trigger window because that's
when the first refresh fires. After the first refresh, the stale cache
poisoned every subsequent request.
Fix: delete the cached session after a successful repository update,
mirroring what SwitchOrganization already does for the same reason
(it updates current_organization_id in Postgres and then drops the
Redis copy). Next GetSession misses, re-reads from Postgres, caches
the fresh nonces.
The deleteSession failure path is intentionally swallowed — the
refresh already succeeded and we returned the new tokens, so worst
case is the next request triggers another refresh, not a logout.
Matthew Meszaros