[morgmart]

Onboarding audit for desktop first run: account-first Builderlab sign-in, recovery for a stalled sign-in, and clearer community setup.

• Sign-in recovery. A sign-in that times out waiting on the browser shows "Finish in your browser" with Continue, not "Sign-in did not finish". Open Buzz (buzz://sign-in) restarts a waiting or timed-out sign-in, including one started from a community address.
• Connect to a community. It's a join-or-create choice, and it only offers "create your own" when Create is available. A refused create replaces "available" and holds Create until the name changes.
• Dark-mode hover fill. Hover fills stay light on light surfaces inside dark mode, so "Other options" is no longer dark text on a dark fill.
• Clear glass button. Rebuilt on the shared primary glass material.

Account details (name, birthday, country) are not in this PR. The in-app form was reverted in the last commit. Public desktop sign-in now goes through the hosted setup page mobile uses: ext-builderbot-ui #403, then cash-server #146925.

Overlaps #2576 in federated_identity/mod.rs and oauth_callback, so it rebases onto #2576 once that lands.

Checks at the head commit: tsc clean, biome clean, full vitest run 17,857 passed / 22 skipped.

[kalvinnchau]

🤖 Two actionable findings: occupied-device recovery can unlink the account key without replacing the device key, and existing-key adoption bypasses account/backup confirmation.

[kalvinnchau]

🤖 [P1] Guard recovery when the device already holds another key

On relaunch with device key A and account key B, Saved key → paste B → Continue never calls identity_import: service.ts:179 rejects operations while identity is ready, but setup.saved accepts A as success. The start-over variant likewise never calls identity_create; it unlinks B and then attempts to bind retained A. A pubkey_already_bound refusal leaves B unlinked and setup failed. Both paths were reproduced through the actual app in Chromium and WebKit with mocked native/account boundaries; no real account was modified. Handle the occupied-device mismatch before exposing missing-key recovery, and verify the expected replacement key before unlinking. Extend the relaunch test through import and start-over.

[kalvinnchau]

🤖 At 83a8fc7, import and Start over now refuse before import/create/unlink; the destructive behavior above is repaired.

[P2] The backed-up recovery branch still hangs: with device key A and account key B whose backup is available, Saved key calls beginRecovery (Welcome.tsx:880–888), but service.ts:97 returns while identity is ready. No nsec_restore_begin occurs, and the undefined recovery snapshot leaves KeyRestore on ‘Restoring your key…’ with only Cancel. An exact-head targeted probe reproduced this. The new tests use backupStatus=unavailable and miss this branch.

The same missing occupied-device UI state also leaves Start over on a misleading failure page: Welcome.tsx:937–948 clears linked/owned before the new guard throws; Try again repeats the refusal and Back returns to the landing. Model the occupied-device mismatch in Welcome back before offering recovery actions, or refuse before changing state, including onRestore. Add a backed-up occupied-device regression case.

[morgmart]

🤖 Addressed in 41572fa. A sign-in that finds another account's key on this device no longer reaches Welcome back. The device key is signed out first, as Sign out of Buzz does without erase, and Buzz restarts and signs in again on the no-key lane. It is signed out silently only when this device has a confirmed backup record for that key (new nsec_backup_confirmed). Otherwise a Replace/Cancel confirm appears, and Cancel leaves the key in place. So the hanging restore and the misleading Start over page are both unreachable from that state. Covered by the new relaunch tests in identity.test.tsx and the persistence test.

[kalvinnchau]

🤖 [P2] Preserve confirmation and opt-outs when adopting an existing key

When the browser account is unlinked, this path binds and backs up the existing device/legacy key without showing the previous account identity and backup confirmation. With an unbound existing key and a backup-capable account/build, a remembered wrong browser account can gain recovery of that identity. backUpWith also writes automatic=true rather than preserving a saved opt-out (backup.ts:187; nsec_backup_choice.rs:204–227), contrary to docs/identity.md:830–837. Confirm account/key and backup before adopting an existing key, and preserve an existing opt-out unless explicitly changed. This is source-level control-flow evidence; no live upload was attempted.

[baxen]

🤖 Approving at 83a8fc7. I reviewed the code changes, not the tests, and CI is green. 83a8fc7 fixes the destructive case @kalvinnchau found: vacant() now refuses before create, import or Start over's unlink can act on a different device key.

Remaining issues. None of them lose data, so I'm fine with them going in a fast follow-up:

1. Occupied device + backed-up account hangs (Kalvin's follow-up P2, I confirmed it). With device key A and account key B where B is backed up, Welcome back → Saved key calls current.recovery.beginRecovery() (Welcome.tsx ~880). identity/service.ts:98 returns at once unless the status is missing. KeyRestore then sits on "Restoring your key…" with only Cancel. Welcome back should treat viewer && viewer !== linked as its own state: hide or disable restore/import and keep Use a different account. The current tests use backupStatus=unavailable, so they miss this branch.
2. Start over on an occupied device clears linked/owned before createKey's vacant() throws. You land on a failure page where Try again just repeats the refusal. It's safe now, but confusing. Check before changing state, or don't offer Start over when another key is on the device.
3. Existing-key adoption skips confirmation (Kalvin's first-round P2, still open). On a relaunch where the account has no key, the device key is linked and backed up with no in-app check. backUp also writes automatic=true over a saved opt-out. The hosted "Continue to Buzz as X" page (ext-builderbot-ui #403) now confirms the account in the browser, so the wrong-account risk is lower. The opt-out overwrite still goes against docs/identity.md. Preserve a saved opt-out, for example with setBackupChoice(..., unlessSaved).
4. Docs drift: docs/identity.md still describes the key choice page ("This choice page shows the signed-in email…") and Sign in with Builderlab. This PR removes KeyChoice, and the landing now says Create account / Sign in.

The rest looks good:

• screen_hint=signup is sent only for an explicit Create account.
• prompt=login is kept across restarts until a sign-in completes. It matches kgoose #147640.
• The sign-in-timed-out code is split out cleanly from callback-refused.
• buzz://sign-in matching is exact, with a 2-minute expiry.
• The Next step splicing in setup.run keeps failed-step retry intact, since steps.slice(index) includes the spliced steps.