Auth: idempotent refresh to close the tab-death cross-tab residual (#169 follow-up) #176

Context

Follow-up from the #169 (PR #175) review (codex). #169 serialises refresh across tabs with the Web Locks API, which eliminates the common multi-tab race. One narrow residual remains that a page-owned lock cannot close:

Tab A acquires the lock and sends refresh token R0. The server commits R0→R1 and sets the rotated cookie, but Tab A is closed/reloaded in the sub-second before the response + Set-Cookie are processed. Unloading auto-releases the Web Lock while the cookie is still R0. Tab B then acquires the lock, presents R0 (now revoked), and trips reuse-detection → whole-family revocation → both tabs logged out.

A lock held by a page cannot make server rotation and cookie receipt atomic, so the client alone cannot fully close this.

Proposed fix (server-side)

Make refresh idempotent for a short window: the client sends a stable per-exchange request id (or the server keys on the presented token + its immediate replacement). A repeat of the same exchange returns the same replacement instead of being treated as a replay, while an unrelated old/stolen token still trips strict reuse-detection.

• Keep strict reuse-detection for genuinely replayed tokens (the Auth: concurrent multi-tab refresh can trip reuse-detection and log both tabs out #169 acceptance criterion).
• Only the immediately-previous rotation, within a few seconds, is treated as idempotent.

Acceptance

• A tab closed mid-refresh does not cause the next tab to be logged out.
• A genuinely replayed/stolen (non-matching) token still revokes the family.
• Tests cover the mid-refresh-tab-death sequence.

Referenced from a code comment in web/src/api/client.ts (#169).