Windows: Desktop refuses to start when the Windows Credential Manager is at capacity

# Windows: Desktop refuses to start when the Windows Credential Manager is at capacity — `identity resolution failed: keyring write: Platform secure storage failure: Windows error code 8`

**Version:** Buzz Desktop 0.5.14 (installed via the in-app updater on 2026-08-15)
**OS:** Windows x64 (build: `Windows 10 Pro 25H2 (Build 26200.8973)`)
**WebView2 runtime:** 151.0.4129.86
**Install path:** `%LOCALAPPDATA%\Buzz`

## Summary

After updating to 0.5.14, the desktop app no longer starts. A window flashes for a fraction of a second and disappears. No error is shown anywhere in the UI, and no crash dump is produced.

The actual cause is that `buzz-desktop` tries to migrate the identity from `%APPDATA%\xyz.block.buzz.app\identity.key` into the Windows Credential Manager and the write fails, after which the process deliberately exits:

```
buzz-desktop: fatal: identity resolution failed:
keyring write: Platform secure storage failure: Windows error code 8
[0815/152626.618:ERROR:ui\gfx\win\window_impl.cc:172] Failed to unregister class Chrome_WidgetWin_0. Error = 1412
```

Windows error code 8 is `ERROR_NOT_ENOUGH_MEMORY`. Coming from `CredWriteW`, it does not mean the machine is out of RAM — it means the user's credential store cannot accept another entry.

## Why this is nearly impossible to diagnose as a user

1. `buzz-desktop.exe` is linked as a **GUI subsystem** binary, so it has no console. Running it from PowerShell prints nothing; the fatal message goes to a `stderr` handle that does not exist. The message only becomes visible if the user knows to redirect it:
```powershell
Start-Process "$env:LOCALAPPDATA\Buzz\buzz-desktop.exe" -NoNewWindow `
-RedirectStandardError "$env:APPDATA\xyz.block.buzz.app\buzz-err.log"
```
2. No crash dump is written (Crashpad `reports/` stays empty) because this is a deliberate exit, not a crash.
3. No startup log file is written anywhere, so there is no trace to inspect afterwards.

From the user's point of view the app is simply dead after an update, with antivirus software being the natural (and wrong) suspect.

## Root cause on the affected machine

The Windows Credential Manager holds 271 entries and is at capacity. This is **not** specific to Buzz — any credential write fails:

```
PS C:\> cmdkey /generic:buzz-vault-test /user:test /pass:test
CMDKEY: Zur Verarbeitung dieses Befehls sind nicht genügend Speicherressourcen verfügbar.
```

(German for "not enough memory resources are available to process this command" — the same `ERROR_NOT_ENOUGH_MEMORY`.)

`VaultSvc` is running normally (`Status: Running`, `StartType: Automatic`), and no Buzz entry exists in the store, confirming the write never succeeded.

Notably, a `CredEnumerateW` call over the full store also returns nothing on this machine, which is consistent with the store having exceeded its overall size limit.

## Steps to reproduce

1. On Windows, fill the Credential Manager until writes fail (verifiable with `cmdkey /generic:test /user:test /pass:test` returning the "not enough memory" error).
2. Install/update Buzz Desktop 0.5.14 with an existing `%APPDATA%\xyz.block.buzz.app\identity.key` present.
3. Launch Buzz. The window flashes and the process exits.

## Expected behaviour / suggestions

1. **Do not refuse to start when `identity.key` is present and valid.** The file is still on disk — it was the authoritative store until this version. A failed keyring write should degrade to file-based identity (with a warning in the UI), not terminate the app. The current behaviour turns a storage-backend preference into a total loss of access to the application.
2. **Surface the failure.** Since the binary has no console, a message box or a startup log file (e.g. `%APPDATA%\xyz.block.buzz.app\startup.log`) would turn a silent exit into a five-minute fix.
3. **Special-case `ERROR_NOT_ENOUGH_MEMORY` (8) on Windows.** It is not transient — retrying, restarting the app, or rebooting will never help. An actionable message such as "Windows Credential Manager is full — remove unused entries under Control Panel → Credential Manager → Windows Credentials" would be enough.
4. The existing message ("retry once the keyring is reachable") is misleading in this case: the keyring *is* reachable, `VaultSvc` is running, it just cannot accept another entry.

## Workaround for other users hitting this

Delete unused entries in **Control Panel → User Accounts → Credential Manager → Windows Credentials** until `cmdkey /generic:test /user:test /pass:test` succeeds, then start Buzz again. Back up `%APPDATA%\xyz.block.buzz.app\identity.key` first — Buzz deletes it once the migration into the keyring succeeds.

Start at the buzz-desktop startup path that migrates %APPDATA%\xyz.block.buzz.app\identity.key into Windows Credential Manager, then trace the CredWriteW failure handling. Reproduce the full-store condition with cmdkey and verify that a valid file identity no longer causes startup to exit, while the storage failure is surfaced with an actionable message.

Written by the indexing model from the issue text.