[Bug][Windows] 0.5.23 shows onboarding on every launch although the identity is in Credential Manager; secrets.buzz-desktop also silently hits the 2560-byte credential limit

[sys6091-source]

Title: [Bug][Windows] 0.5.23 shows onboarding on every launch although the identity is in Credential Manager; secrets.buzz-desktop also silently hits the 2560-byte credential limit

Environment

• Buzz Desktop v0.5.23, Windows 10 Home 22H2 (19045)
• Hosted community relay
• 11 managed agents (3 built-in + 8 custom)

Problem 1 — onboarding on every cold start (same as #7712, which was closed)

Every launch shows the onboarding screen ("Create a new identity key" / use existing key),
even though LegacyGeneric:target=secrets.buzz-desktop contains a valid identity entry.

Timeline from one reproduction (local time, 2026-09-21):

• 12:42:51 credential LastWritten updates (app rewrote the blob while I was signed in; blob contains identity)
• 12:48:58 buzz-desktop.exe started -> onboarding screen shown
• 12:49:45 signed in again via mobile QR -> identity.migrated rewritten, credential LastWritten unchanged

So the key is present and unchanged across the restart, but the cold-start check does not
treat the session as signed in. A user-level BUZZ_PRIVATE_KEY does not change this.
The onboarding screen puts "Create a new identity key" next to the recovery path; pressing it
by mistake is destructive, which makes this bug dangerous rather than just annoying.

Problem 2 — secrets.buzz-desktop silently overflows CRED_MAX_CREDENTIAL_BLOB_SIZE

All secrets (human identity + every managed-agent key) are stored as one JSON object in a
single generic credential, encoded as UTF-16.

• Windows limit: 2560 bytes per credential blob = 1280 UTF-16 chars
• identity entry ~76 chars, each "agent:<64 hex>":"<nsec>" entry ~139 chars
• => hard ceiling of identity + 8 agent keys (1190 chars = 2380 bytes). A 9th key cannot fit.
• The 3 built-in agents take 3 of those 8 slots, leaving 5 for user-created agents.

Observed behaviour at the ceiling:

• With the blob full (2380 bytes), the credential's LastWritten stayed at 2026-08-31 for three
  weeks across many sign-ins, agent creations and an upgrade: no write succeeded, no error shown.
• identity.migrated was still (re)written on each sign-in although the keyring was not updated.
• After deleting agents, the next write succeeded immediately (LastWritten updated), one
  plaintext agent key was migrated in, and the blob was full again at exactly 2380 bytes.
• Agents whose keys do not fit keep private_key_nsec in plaintext in managed-agents.json.
• During the period when writes failed, 3 agents ended up with no key in either store.

Suggested fixes

1. Store one credential per secret (e.g. target buzz-desktop/agent:<pubkey>), or at least
   encode the blob as UTF-8 to double the capacity.
2. Surface keyring write failures instead of failing silently, and do not write
   identity.migrated unless the read-back verification actually succeeded.
3. Fix the cold-start signed-in check on Windows ([Bug][Windows] Desktop shows onboarding ("Create a new identity key") despite valid, actively-authenticating session #7712), and separate/confirm the
   "Create a new identity key" action so it cannot be hit by accident during recovery.

No secrets are included above; sizes and timestamps were read from credential metadata only.