fix(desktop): use effective readiness for welcome kickoff

[loganj]

🤖

Summary

Buzz creates Bumble, Fizz, and Honey during Welcome, then decides whether to start them. That decision was made with a frontend shortcut that did not use the configuration the backend would actually use to spawn the selected agent.

This produced different failures depending on the build:

Build / setup	Before	After this change
Internal macOS release cut by squareup/buzz-releases with packaged Databricks defaults	Welcome looked only at the empty per-install settings file, incorrectly said a provider was required, and left the starter team idle—even though spawn already had a provider, host, and model from the release build.	Welcome evaluates the selected Fizz instance through the backend. It sees the packaged defaults, starts all three agents, and posts the live Fizz kickoff.
Development app with a ready non-Buzz runtime (for example, a selected CLI runtime that is installed and logged in)	Welcome's broad frontend check could inspect a different available runtime than the one assigned to the starter team, so its decision could disagree with the eventual spawn.	Welcome checks the exact Fizz instance and its selected runtime. A runtime that spawn can use is started; one that spawn cannot use is reported not ready.
Fresh development app-data with no packaged defaults, no logged-in CLI runtime, and no credentials of its own	Not ready.	Still not ready. This change intentionally does not copy credentials from the main Buzz identity or invent configuration. The user must configure or log in to a runtime in that development app identity.

The root problem was therefore not that spawn lacked provider/model support. Spawn already resolves the managed instance's selected runtime and its effective configuration in this order: packaged release defaults, app-wide defaults, persona settings, and instance settings. Welcome used a separate approximation over persisted app-wide settings and could disagree with spawn.

This change adds a backend readiness command for one managed-agent instance and makes Welcome call it for the Fizz instance it just provisioned. The command reuses spawn's fallible runtime resolution and effective configuration. It also preserves spawn's behavior for references to deleted runtimes: those remain not ready instead of silently falling back to another runtime.

Provider credentials remain isolated to each Buzz app identity. This change does not copy credentials, persist packaged defaults, or change what Skip for now means. It fixes builds that already have a spawn-ready path but Welcome fails to recognize it; it does not make an actually unconfigured development sandbox ready.

The packaged Databricks floor is an intentional Block distribution boundary, not part of ordinary local or public builds. The private squareup/buzz-releases macOS pipeline supplies BUZZ_BUILD_BUZZ_AGENT_PROVIDER and BUZZ_BUILD_AGENT_ENV when compiling block/buzz; normal just dev and public/OSS release jobs do not. This PR consumes that existing floor consistently but does not change which builds receive it. Making pristine local development reproduce the internal first-run agent experience would require a separate sanctioned dev configuration/authentication path.

Related issue

No exact issue found. Related reports: #4157, #3013, #2931, #3727, and #3753.

Testing

Core behavior was validated at 38d1a13e75161df116e5c77f50b0fb330b44c37b; the follow-up CI-only size-ratchet adjustment is 2a7b2c36ff2f5ddbe2d23b92086cd497bc5b0e00:

• At 38d1a13e75161df116e5c77f50b0fb330b44c37b: full desktop Tauri Rust suite (2,050 passed, 0 failed, 14 ignored), plus pnpm -r check
• At current head 2a7b2c36ff2f5ddbe2d23b92086cd497bc5b0e00: pnpm --dir desktop check:file-sizes and pnpm --dir desktop check
• Playwright onboarding regression: a first-run install with empty persisted agent settings uses packaged defaults and posts the live Fizz kickoff
• Regression coverage for selected-runtime readiness, release-default and provider fallback behavior, and deleted-runtime references

The manual fresh-install walkthrough was blocked by macOS Accessibility automation, so the automated first-run flow provides the reproducible end-to-end coverage.

[bradhallett]

Heads-up on a readiness.rs overlap @loganj — #3804 patches resolve_effective_harness_descriptor in desktop/src-tauri/src/managed_agents/readiness.rs (preset launch-args fallback for command-override agents with no runtime id). This PR's readiness.rs rewrite touches the same function territory.

To minimize rework on both sides it'd help to land #3804 first: it's a small, targeted else-branch addition, so your rewrite would only need to preserve that one branch on rebase. The reverse — this landing first — would mean rebasing a surgical fix against a large function restructure.

#3804 is now rebased onto main, conflict-free, and mergeable (waiting on review only). Flagging now so neither of us eats an avoidable rebase — happy to coordinate sequencing either way.