Refresh-token reuse no longer kills the session family

This is the single most important security property in the entire service: if a refresh token is ever stolen, the system's only way of noticing is that the legitimate client eventually presents the token too, after the thief has already used (and rotated) it. That replay is supposed to be treated as a full compromise signal and kill every token in the session family, forcing a real re-login. Right now it does not: an attacker who steals a refresh token and rotates it once keeps a fully working, never-flagged session indefinitely -- the exact scenario this whole project's headline feature was built to prevent is currently silently disabled.

rotate_refresh_token() checks row.revoked_at is not None before row.replaced_by is not None. A rotated token always has both set together (written two lines apart, immediately before the same commit, in the rotation code path itself), so for any already-rotated token the revoked_at check is always true first and the function returns before ever reaching the replaced_by check -- meaning revoke_family() is never called on a replay.

1. Log in, get refresh token A.
2. POST /auth/refresh with A -- rotates to token B.
3. Replay A: POST /auth/refresh with A again -- returns 401 (looks correct).
4. Try B: POST /auth/refresh with B -- currently 200. Should be 401: A's replay should have killed the whole family, including B.

This is deliberately the hardest ticket in the set because the regression is invisible from the outside unless you specifically think to check the successor token, not just the replayed one. Every other observable signal -- the replay attempt itself getting rejected, every other 2FA/session/password-reset flow, every other existing test -- stays green. It is a strong example of how a refactor-looking, "just reordered two checks" change can silently disable a security control while every test that only checks "was the bad request rejected" keeps passing.

Work out what row.revoked_at is not None and row.replaced_by is not None each mean independently -- is there a RefreshToken row where one is true and the other is false? Under what circumstance? Which of the two checks needs to run first for the revoke_family() branch to ever be reachable for a rotated token specifically (as opposed to a token revoked some other way, e.g. via DELETE /auth/sessions/<id>)?