fix(accounts): keep the switcher within the keychain's value cap

[kipavy]

Reported on Windows: after adding a second account through "Add another account…" and switching back, the persistent sessions never reopened — no tabs at all — and the second account was gone from the switcher.

Root cause

Both symptoms come from one place. The switcher kept every saved account, and each one's parked UI state, in a single keychain value. Windows Credential Manager refuses a credential blob over CRED_MAX_CREDENTIAL_BLOB_SIZE (2560 bytes), checked after UTF-16 encoding, so 1280 ASCII characters. With real tokens one entry is ~940 characters and two are ~1890 — past the cap. Every call site swallowed the rejection.

• The second account vanished: saving it threw, silently, so the keychain kept the one-account list. On the way back the next save read that stale list and rewrote it, erasing the account for good.
• The tabs vanished: parking the outgoing account's workspace snapshot in that same value was over the cap before it started. The park failed, localStorage had already been cleared, and the switch back had nothing to restore.

Unit tests never caught it because they fake an unbounded keychain — and on Linux/macOS the Secret Service and Apple keychain have no comparable cap, so it only bites Windows (and headless Linux, where the linux_keyutils fallback caps 20 KB per user for everything).

Changes

• One keychain entry per account (voltius.saved_account.<id>) plus an index of ids. A pre-0.29 single-value list migrates on first read, and leaves the old value alone if a write fails so it can retry.
• UI state parks in localStorage (voltius.parked-ui-state.<id>), where the same data already lives while the account is signed in. It runs to kilobytes — workspace snapshot, command history, snippet variables — and never belonged in a keychain value. Signing an account out drops its parked copy.
• A failed read no longer looks like an empty switcher. loadSavedAccounts returns { ok, accounts }; ok: false blocks the write that used to persist that emptiness over real accounts.
• Failures are said out loud: a toast from the account menu (layout.sidebarAccount.saveFailed, 4 locales), a console.warn on the splash, and "Add another account" aborts rather than signing the account out when it could not be saved first.
• Workspace restore waits for the replace-mode login sync. A switch wipes the config dir, so reconnecting before the cloud pull refills it finds no connection and errors every restored tab. A normal launch reads its cache from disk and never waits. The gate moved out of plugins/runtime.ts into src/services/loginSyncGate.ts.

Tests

savedAccounts.test.ts now drives a keychain fake that enforces the real cap (2560 bytes, UTF-16), which the previous layout cannot pass, plus tests for the legacy migration, a refused migration, and the unreadable-keychain case. workspaceRestore.test.ts is new and was confirmed to fail with the gate line removed.

Full suite 3582 passing, tsc --noEmit clean.

Not verified here

The trigger is Windows-only, so no run on this machine can reproduce the original failure — this needs an add-account → switch-back on Windows to confirm in the wild.

Known residual, deliberately left: between the localStorage clear and the reload, a late zustand persist write could hand the outgoing account's in-memory state to the incoming one. Pre-existing and narrow; closing it means quiescing the stores.