[BUG] Mobile attach to ONE specific local session returns 401 'OAuth access token expired' after account token rotation; bridge binding is server-authoritative and survives every local remedy

Symptom

After a forced account re-login (token rotation) on desktop, the Claude mobile app can no longer attach to one specific local session. That session shows "Failed to authenticate — API error 401 OAuth access token expired, re-authenticate to continue." Every OTHER local session attaches from the same phone without issue, and the affected session works perfectly from the desktop app (local attach). This matches the shape of #30102 but persists through every remedy including the fixes shipped in 2.1.203–2.1.216.

Environment

• Claude Code: was 2.1.132 at incident start; updated to 2.1.220 mid-incident (no change)
• Desktop app: Claude.app 1.24012.11, macOS (Darwin 25.5.0)
• Mobile: Claude Android app (updated during incident; no change)
• Session type: long-running local session (~6 days uptime at incident)

Remedies attempted, in order (none worked for the affected session)

1. Phone: airplane-mode cycle, app restart, full sign-out/sign-in (Google SSO), force stop + clear cache, device reboot
2. Desktop: full app quit/reopen ×3 (session resumed fine locally each time)
3. CLI updated 2.1.132 → 2.1.220; engine process for the session restarted fresh (new PID, post-update binary, fresh keychain credentials) — phone still 401s on this one session
4. Forensic finding: the session's record file (~/Library/Application Support/Claude/claude-code-sessions/<env>/<project>/local_<id>.json) carries bridgeSessionIds: ["session_013odgGSRGUSbnxbvPWDq8hc"]. Clearing this field on disk while the app was RUNNING → the app rewrote the old id back from memory within minutes. Clearing it while the app was fully QUIT (verified via a watcher that edited only after the last app process exited) → on relaunch the app restored the same old bridge id anyway, indicating the binding is authoritative on the server side and merely mirrored locally. No local operation can force a re-registration.
5. A brand-new session created the same evening (fresh bridge id) attaches from the same phone instantly — confirming account, network, app, and relay are all healthy. Only the pre-rotation bridge binding is poisoned.

Ask

• A per-session re-registration path (CLI or UI) that tears down and re-mints a session's remote/bridge registration without archiving — archiving is currently one-way in the desktop app (see #67835 / #62428 / #30869), which makes it unusable as a remedy for long-lived sessions users care about.
• Server-side: invalidate/refresh bridge bindings when account tokens rotate, instead of leaving sessions bound to dead credentials.

Happy to provide timestamps/logs privately. The affected bridge id above is included deliberately to aid server-side lookup.