fix(auth): quarantine corrupt accounts.json instead of overwriting it

[icebear0828]

Why

Reported in conversation: users updating from 2.0.71/2.0.72 → 2.0.73 on Windows had their accounts.json silently emptied (file content became { "accounts": [] }). Reading the code:

1. loadPersisted (src/auth/account-persistence.ts) caught readFileSync / JSON.parse / non-array failures with a console.warn and returned { entries: [], needsPersist: false }.
2. AccountPool built the registry from those empty entries.
3. The next mutation (refresh-scheduler tick, dashboard action, release()) hit schedulePersist, and 1 s later persistence.save([]) overwrote the on-disk file with the empty map.

A single transient read failure — Windows AV scan locking the file, NSIS upgrade killing the process mid-renameSync, a half-written file from a prior crash — was enough to delete the entire account list. No error surfaced in the UI; users only noticed when the dashboard showed zero accounts.

What

Three coordinated changes prevent this from happening again:

1. Quarantine the corrupt file. quarantineCorruptFile renames the unparseable accounts.json to accounts.json.corrupt-<ISO timestamp>.bak, preserving the original bytes for forensics. appendErrorLog({ source: "server", name: "AccountsFileLoadFailed", context: { reason, accountsFile, quarantined, backupPath, rawByteLength } }) so the Errors tab + header badge surface the failure on next dashboard load. Best-effort: if the rename fails, the file stays where it is and the next launch will hit the same code path — still better than silent overwrite. Missing file is not a failure (first-run keeps loadFailed=false).
2. Circuit-breaker on persistence. AccountPersistence.load() returns a new optional loadFailed: boolean. AccountPool threads it into new AccountRegistry(..., { persistDisabled }). schedulePersist and persistNow short-circuit when disabled, so the empty in-memory map can never overwrite anything. In-memory CRUD still works for the running session — users can keep operating until they restore the file and restart.
3. Dashboard banner. GET /auth/accounts response gains persistence_health: { ok, reason, message }. useAccounts reads it; AccountManagement renders an amber "Auto-save paused" banner pointing users at data/accounts.json.corrupt-*.bak. i18n keys persistDisabledTitle / persistDisabledBody for en + zh.

Recovery path for affected users

1. Open the dashboard — the new banner shows up if accounts.json was corrupt at startup.
2. Inspect data/accounts.json.corrupt-<timestamp>.bak (on Windows: %APPDATA%\Codex Proxy\data\). If it's intact JSON with accounts, rename it back to accounts.json. If it's a half-written file, restore from any other backup (Codex Desktop's ~/.codex/auth.json, an earlier RT-only export, etc.).
3. Restart the app. Healthy load → banner clears, auto-save resumes.

Test plan

• tests/unit/auth/account-persistence-load-failsafe.test.ts — 6 cases: malformed JSON, 0-byte file, wrong shape (accounts not an array), missing file, healthy file, repeat-failure timestamp uniqueness.
• tests/unit/auth/account-registry-persist-disabled.test.ts — 6 cases: schedulePersist no-op, persistNow no-op, addAccount memory-only when disabled, pool.isPersistDisabled() reflects loadFailed, background mutations don't reach disk, healthy path regression.
• tests/unit/routes/accounts-persistence-health.test.ts — 2 cases: GET /auth/accounts returns persistence_health: { ok: true } on healthy load, { ok: false, reason: "load_failed_quarantined", message: ... } on failed load.
• Full suite: 1940 passing / 1 skipped / 0 failed.
• tsc --noEmit clean.
• Manual verification on the affected Windows machine (out of band — requires the user's environment).

Out of scope

• Auto-recovery from .bak file (user must rename manually + restart). Keeping this explicit so we don't silently restore a stale or wrong-version backup.
• Periodic backup snapshots of accounts.json. Reasonable future addition, but separate change.