Make first-run Builder setup recoverable

[steve8708]

Changes

• Distinguish creating a Builder.io account from signing in with an existing account in all Toolkit locales.
• Keep a return path to setup choices after Builder connection or provisioning failures so users can choose manual keys or skip.

Evidence

Clips onboarding replay data records Builder provisioning requests returning 503 after the user clicks the setup action. The app already distinguishes pre-click status-read failures and offers retry after connection failures; this adds recovery back to the original choices.

Validation

• FirstRunOnboarding.spec.tsx: 48 tests passed
• Clips storage setup and home routing suites: 58 tests passed
• Toolkit typecheck passed
• pnpm guards: all 89 checks passed

[github-actions]

Visual recap — readback failed

The recap was published, but the workflow could not verify it. Screenshot capture was skipped. Open the interactive recap directly:

Open the full interactive recap

Diagnostic:

Published recap readback failed: get-visual-plan returned HTTP 403; the configured token cannot read this published recap

[builder-io-integration]

Builder reviewed your changes and found 1 potential issue 🟡

Review Details

Incremental Code Review Summary

This update resolves the prior account-state finding: failure handlers now restore the captured account state only when a fresh status was unavailable, and new desktop/embedded tests verify fresh status wins after launch failures. The cancellation test now reflects that connecting remains true immediately after Cancel and checks the Back path after the UI settles. The main remaining concern is that production cancellation does not settle promptly: the popup-closed poll path can leave the user waiting through the 20-second confirmation grace period before Back appears. The implementation direction is sound, but cancellation feedback should be immediate or visibly acknowledged.

Finding

🟡 MEDIUM — Back remains unavailable during cancel confirmation grace: cancel() records closure but leaves connecting true, while the new Back control requires !connecting. Users therefore remain on the in-progress UI for about 20 seconds after choosing Cancel.

A low-severity test note about manually simulating the later settled state is also passed for filtering. 🧪 Browser testing: Skipped — browser-test-planner is not available in this environment; no browser test results exist for the PR yet.

[builder-io-integration]

Builder reviewed your changes and has a few items to flag 🟡

Review Details

Incremental Code Review Summary

This update adds localized “checking connection status” feedback while a Builder cancellation settles, plus resets the cancellation state when a new Builder attempt begins. The account-status restoration changes and associated desktop/embedded tests remain consistent with the previous review. The parallel review agents found no new confirmed issues in this update; one agent was unable to inspect source due to its ACL, so the result is based on the other completed reviews and the readable diff.

The prior open comment about Back being unavailable during the cancellation grace period remains unresolved: the new message acknowledges the wait but does not make setup choices immediately accessible. I have not reposted that existing issue. 🧪 Browser testing: Skipped — browser-test-planner is not available in this environment; no browser test results exist for the PR yet.