fix(users): harden the session_version cache - #311

`_TOKEN_LIFETIME_SECONDS` is one number for the whole process — `current_user`
resolves its strategy from the shared backend, so it cannot vary per request —
and it has to be the widest window any sign-in asks for. Every other credential
inherited it. An ordinary sign-in wrote an `sm_auth` cookie whose `Max-Age` said
fourteen days while the row behind it was accepted for thirty, and `Max-Age` is
browser-enforced only: a cookie lifted off disk is replayed without one. That is
exactly the hole `SESSION_EXPIRES_AT_KEY` closed for the session cookie.
`/api/users/auth/token` had the same shape in reverse — it returned
`expires_in=900` for a row good for a month, so a client that honoured it
re-authenticated every fifteen minutes while the token it discarded stayed live.

`UserAccessToken` now carries its own `expires_at`, stamped from what that
sign-in actually asked for (`cookie_max_age_seconds`,
`remember_me_max_age_seconds`, or `bearer_token_lifetime_seconds`), plus the
`session_version` it was minted under. `ExpiringDatabaseStrategy` stamps both and
enforces them, and `_resolve_bearer` applies the same two clauses in SQL — so the
two bearer readers agree rather than drifting. The process-wide constant stays as
the read *ceiling*: narrowing it would reject the longer rows a remembered
sign-in legitimately wrote.

The stamped counter is the revocation `_resolve_bearer` never had. A password
change bumped `session_version` and stranded every session while every bearer
token minted before it kept working — including any an attacker who knew the old
password had already collected. `change_my_password` now also deletes the access
tokens and revokes the refresh tokens, matching the bearer half of
`revoke-all`: the counter alone strands them, but leaving the rows lets a stolen
token resolve until its own deadline and lets refresh tokens mint replacements.
`token_refresh` re-reads the account rather than trusting `rt.user_id`, since a
refresh token outlives the access tokens it mints.

The migration backfills both columns with the values existing rows were actually
minted under — thirty days from `created_at`, and the owning account's counter —
so upgrading signs nobody out and leaves no NULL for the read path to fail open
on.

Last, the legacy session fail-open. `session_has_expired` accepted a session with
no deadline, with nothing tracking when that could safely be closed. The provider
now stamps one on first sight (`ensure_session_expiry`), which can only tighten:
the signer independently enforces the signature window from the session's
original mint time, so a stamp written now cannot outlast the ceiling the session
already had. Nobody is signed out, and with the only caller stamping first,
`session_has_expired` fails closed on absence.

Closes #292

Both conflicts are this branch's version against the squash-merged #292, which
this work was stacked on: the RequestSession annotation and the post-commit
invalidation supersede the inline forget_session_version calls that landed
with the token-expiry change.