Give Cursor's Agent mode a security invariant list before it touches an authentication flow

AUTH CHANGE
Add refresh-token rotation: each refresh issues a new refresh token and invalidates the one used, instead of reusing the same refresh token indefinitely.

CURRENT FLOW
Access tokens expire after 15 minutes; refresh tokens are long-lived (30 days) and currently reusable without rotation.

SECURITY INVARIANTS — none of these may change as a side effect of this work, even temporarily during development
An expired access token is always rejected, no exceptions for internal service calls. A revoked refresh token can never mint a new access token, even once. No endpoint issues a token without passing through the shared verifyCredentials() path.

TOKEN / SESSION HANDLING RULES
Refresh tokens are compared using a constant-time hash comparison, never a plain string equality check, and are never stored in plaintext in the database.

AFFECTED CLIENTS / SERVICES RELYING ON CURRENT TOKENS
The mobile app caches a refresh token client-side for up to 30 days; roughly 40,000 active refresh tokens exist under the current non-rotating scheme at any time.

Implement the change above. While doing it:
- Never log a raw token, password, or secret value, even at debug level and even temporarily to check something — log an identifier or a boolean instead.
- Never weaken an existing check (an expiry, a signature verification, a scope check) to make a test pass or unblock local development with a plan to "tighten it back up later" — if a check is genuinely in the way of the change, say so explicitly and ask, don't route around it.
- Do not add a new code path that can produce a valid session or token without going through the same verification the existing paths use, even for a supposedly low-risk case like a test harness or an internal admin tool — that becomes the eventual weakest link.
- If the change touches token expiry, refresh, or revocation, state explicitly what happens to a token that's mid-flight — issued before the change, used after it ships — since a change that silently orphans or silently keeps trusting an old-format token is a real gap even when new tokens are handled correctly.

BEFORE FINISHING
Go through SECURITY INVARIANTS one at a time and state, for each, whether it still holds after your change and how you'd verify that — not just an assertion that it does. If any invariant is genuinely in tension with the requested change, stop and name the conflict rather than silently deciding which one wins.