fix(users): bound each bearer credential by what it was issued for - #309

Closes #292

The problem

_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 (30 days, for "keep me signed in"). Every other credential inherited it:

• A non-remembered sign-in minted a 30-day credential. auth_backend.login wrote an sm_auth cookie with a 14-day Max-Age, but the row behind it was accepted for 30. Max-Age is browser-enforced only, so a cookie lifted off disk is replayable for a month — exactly the hole SESSION_EXPIRES_AT_KEY closed for the session cookie.
• /api/users/auth/token lied about expires_in. It returned bearer_token_lifetime_seconds (15 minutes) for a row good for 30 days, so a client that honoured it re-authenticated every 15 minutes while the token it discarded stayed valid.
• A password change did not revoke bearer credentials. change_my_password bumped session_version and stranded every session, but deleted no UserAccessToken rows, and _resolve_bearer never read session_version at all — unlike _load_user, which does.
• The legacy session fail-open had no end date. session_has_expired accepted a session with no expires_at, with the docstring pointing at a future revisit that nothing tracked.

The fix

Each row now carries the two bounds the session path has: its own expires_at, stamped from what that sign-in actually asked for, and the session_version it was minted under.

ExpiringDatabaseStrategy stamps both and enforces them; UsersAuthProvider._resolve_bearer applies the same two clauses in SQL, so the two readers of users_access_token agree rather than drifting. _TOKEN_LIFETIME_SECONDS stays as the read ceiling — narrowing it would reject the longer-lived rows a remembered sign-in legitimately wrote.

The stamped counter is the revocation _resolve_bearer never had. On top of it, change_my_password now 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 keep resolving until its own deadline, and lets refresh tokens mint replacements behind it. token_refresh re-reads the account rather than trusting rt.user_id, since a refresh token outlives the access tokens it mints.

Migration b4c1e7d9a025 backfills both columns with the values existing rows were actually minted under — 30 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. Verified against a scratch SQLite DB seeded under the old schema: a legacy row came out with expires_at = created_at + 30d and session_version = 7 inherited from its user.

The legacy session fail-open is closed without a deploy-time mass sign-out. The provider stamps a deadline on first sight (ensure_session_expiry), which can only ever tighten: the signer independently enforces SESSION_SIGNATURE_MAX_AGE from the session's original mint time, so a stamp written now cannot outlast the ceiling the session already had. A remembered legacy session is stamped with its recorded window rather than demoted to 14 days. With the only caller stamping first, session_has_expired now fails closed on absence.

Verification

• uv run pytest -q (full suite) — 2806 passed, 2 skipped, 60 deselected
• uv run pytest modules/users framework/hosting — 973 passed (21 new)
• Fail-before proof: reverting the three enforcement points (the expires_at clause, the token_is_live check, the ensure_session_expiry call) and the fail-closed flip fails 7 of the 21 new tests — the provider refusing an expired row, the version bump stranding a token on both paths, the three session_has_expired absence cases, and both stamping cases. All restored, all pass.
• Migration applied cleanly on a scratch SQLite DB; backfill asserted programmatically (see above).
• ruff format --check / ruff check / ty check modules/users framework/hosting / check_file_size.py / make doctor — all pass

Notes for review

• The Authorization: Bearer header is read by UsersAuthProvider via AuthMiddleware, not by fastapi_users.current_user — the shared backend's transport is a CookieTransport. The tests probe each reader the way the app actually reaches it (sm_auth cookie for the strategy, _resolve_bearer directly for the header), rather than assuming one header exercises both.
• UserAccessToken.expires_at has a 30-day default factory for a caller that builds the model by hand. Both real mint paths always stamp explicitly; the default keeps that fallback no worse than the old behaviour rather than minting something that never expires.