fix(auth): answer a refresh burst with one successor token

[henfircreo]

Problem

This follows up the refresh-token grace window that shipped in 0.0.515 (REFRESH_REUSE_GRACE_SECONDS, 0102_session_rotated_at). Inside the window, a spent token rotated the session again. In a burst of refreshes on one cookie (every tab's timer firing after a laptop wakes), the first request rotates the row and the second rotates it again inside the grace window. The third then matches no previous hash and gets a 401, and its response clears the cookie the other two had just set. The session stays active and the browser loses it. In production we still saw sign-outs after the grace window landed.

Second, a refused refresh left the console signed in: every request answered 401, and the chat socket reconnected on a dead token until the person did a full reload.

Change

• One successor per spent token. successor_refresh_token derives the next refresh token from the spent one: jti is an HMAC (keyed with SECRET_KEY) of the spent token's hash, exp is the row's own expiry, and the payload has no iat. The same spent token therefore always produces the same successor, byte for byte. Within the window, SessionService.reissue_within_grace answers with the token the row already holds instead of rotating again. Every request in the burst gets the same token, so the cookie ends up the same whichever response lands last. The row never stores a credential.
• The grace answer is refused when the row has rotated past that successor (a later refresh on the new token) or the account's credential version has moved. Reuse detection outside the window is unchanged, and so are upstream's guards against a rotation stamped in the future.
• A 401 from the refresh logs the console out (api-client.ts), so AuthGuard sends the person to sign in. A rate limit, a 5xx or an ended impersonation is still not treated as the end of the session.
• The chat socket's /auth/me recovery tolerates an empty answer.
• Docs (configuration, security in en/pl/de/es) and the CHANGELOG describe the reissue.

Verification

• tests/test_session_refresh_grace.py: the successor is deterministic, differs between spent tokens and carries the given expiry and version. The reissue is refused once the row has moved on or the credential version has changed.
• tests/integration/test_session_revocation.py, through the real route: a lost response gets back the token it missed; a burst of three gets 200 and the same token on every request; once the successor has rotated, the spent token gets a 401; and a password change closes the window.
• api-client.test.ts: a 401 refresh logs out, and a 429 or 5xx does not.
• Locally: these backend tests, tests/api/test_auth.py (51 passed), and api-client/use-chat/auth-lock vitest (185 passed). ruff is clean, and check_docs_i18n.py reports every translation current.

Limitations

The tradeoff is the same as the existing window: a stolen refresh token replayed within REFRESH_REUSE_GRACE_SECONDS of the victim's own refresh is answered rather than detected. The difference is that it now receives the token the victim also holds, rather than a fresh rotation.

[DEENUU1]

Thanks @henfircreo — merged as #2018. Maintainer edits can't push to a branch on an organization-owned fork, so your commit was carried unchanged on a vstorm-co branch with main merged in; it ships in 0.0.521.