[loganj]

Summary

First-run setup could trap people on Couldn't finish setup, with only Try again, which repeated the same failure forever. The common path: sign in to Buzz, sign out, then sign in with a different Builderlab account. Buzz then tried to link a key that belongs to the first account to the second one. Builderlab refused, and nothing on screen led anywhere else.

This PR removes the trap in three places:

• Key from an older Buzz install. Buzz no longer saves that key before it knows the account can use it. If the account accepts it, Buzz saves it as before. If it belongs to another account, Buzz makes a new key and continues.
• Another account's key already on this computer. Buzz now always asks Replace or Cancel. Before, it sent people to the dead-end page. When that key has a confirmed backup, the dialog says so and tells the person how to get it back: sign in to that account again. Cancel returns to the start page with the key kept.
• Any setup failure after a Builderlab sign-in. The failure page now offers Use a different account. It signs out of Builderlab, keeps any key on this computer, and returns to the start page. The next sign-in asks for credentials again, so the person can choose another account. Before, some of these failures offered only Back, which kept the Builderlab session, so signing in again reached the same account. Back remains only for failures before any sign-in.
• Try again only where it can help. When Builderlab refuses the link because the key or the account is already bound elsewhere, the page no longer offers Try again, which would get the same answer every time. Use a different account is the only button.

No key is removed without the person choosing Replace.

Linking the old Buzz key before saving it opens one narrow gap: Buzz links the key, then quits or fails to save it. On the next sign-in, the account holds a key this computer lacks, and with no backup, Welcome back could offer only "paste your private key" or "start over". Buzz now checks old Buzz's key first. When it is the account's key, Buzz saves it, backs it up and continues. Old Buzz's own storage is never changed.

Screenshots

1. Key from an older Buzz install belongs to another account

Before: failure	Before: after Try again	After: setup continues with a new key

2. Another account's key is already on this computer

Before: the same refusal, and Try again repeats it.

Before: failure	Before: after Try again

After: Buzz asks. The wording depends on whether that key has a confirmed backup.

No confirmed backup	Confirmed backup

Cancel: back to start, key kept	Replace: Buzz restarts	Setup continues with a new key

3. The account is already connected to another Buzz identity

Before: only Try again	After: Use a different account, and no Try again	After: back to start, key kept

Details

• Older Buzz key. Native code signs Builderlab's link challenge with the old key, but only while no key is saved, and saves nothing. It reads the old storage once and keeps that key in memory. The key it saves is then the same key that signed, even if the old storage changes in between. If the key is missing or malformed, or the person denies the macOS Keychain prompt, Buzz makes a new key. Any other failure, such as an expired link challenge or a busy or locked Keychain, stops setup with Try again, which tries old Buzz's key again.
• Recovering a linked old Buzz key. This runs only after a first run on this computer noted that it was linking old Buzz's key and never saved it, and only when the account holds a key that is neither on this computer nor backed up. Other sign-ins never bring up the macOS prompt for old Buzz's storage. Native code saves old Buzz's key only when its public key matches the account's key. Otherwise it saves nothing, reports no error, and Welcome back shows as before.
• Refusals that lead to the replace dialog. Builderlab can refuse a link because the key is bound to another account, or because the account is bound to another key. Both now lead to the replace dialog.
• "Confirmed backup". This uses the same local check as the rest of the app: a saved, decrypted backup record for this key. It does not call Builderlab. The check only changes the dialog wording. Buzz still asks either way.
• Use a different account shows on any setup failure after a Builderlab sign-in, including the sign-in a relaunch waits on. The next sign-in asks for credentials again instead of reusing the browser's session, which would sign in to the same account.
• docs/identity.md describes the new behavior.

🤖 Generated with Claude Code

[tellaho]

🤖 Design review at b2935e953f7a74054d113d50547fdbc7da4989b5: no design blockers found in the source and supplied light-theme screenshots.

The change gives people a way out of account conflicts while keeping replacement an explicit choice. The shared confirmation retains Cancel before destructive Replace; the failure page replaces an ineffective retry with an account-switch action.

Not checked: native sign-in, keychain/backup/restart behavior, live keyboard or screen-reader use, dark theme, narrower windows, enlarged text or long copy. No tests run.