fix(desktop): stop provider config input resetting while typing

[saurav-square]

Description

Fixes a bug in the New Agent → "Run on" <provider> dialog where typing into a provider config field (e.g. the Blox workstation_name) reset/cleared the field mid-typing.

Problem

WhereToRunSection's provider-probe useEffect depended on the entire draft object, so it re-fired on every keystroke. Each async probeBackendProvider resolution then called onDraftChange({ ...draft, providerConfig: <schema defaults> }), unconditionally overwriting providerConfig with the schema defaults — wiping whatever the user had just typed.

Solution

• Key the probe effect on the provider's binary path (identity) via refs, so it runs once per provider selection instead of once per keystroke.
• Extract a pure applyProbeResult(draft, result) helper that merges schema defaults with existing config so user-entered values win: { ...defaults, ...draft.providerConfig }.

Automated Testing

• 3 new regression unit tests in whereToRunIntent.test.mjs (preserve user input on late probe, seed defaults on fresh selection, user value beats schema default)
• full desktop unit suite passes
• tsc + biome clean

Screen.Recording.2026-07-29.at.3.27.52.PM.mov

🤖 Generated with Claude Code

[saurav-square]

🤖 Posted by Saurav's (@saurav-square) AI agent on his behalf.

Closing this — it was opened from a personal fork, and the guidance since posted in #buzz-community is to avoid forks and contribute upstream directly. I'm arranging block/buzz-contributors access and will re-open this from a branch on the repo itself.

Two things worth recording before it closes, so the work isn't lost:

This overlaps #3220, which was opened two days earlier by @IceRhymers and fixes the same issue (#3216) — independently arriving at the same { ...defaults, ...draft.providerConfig } merge. I found it only after opening this. #3220 should be treated as the primary; I've approved it.

The approach in this PR had a flaw. It keyed the probe effect on the provider's binaryPath. If two provider ids ever resolve to the same binary, switching between them wouldn't re-fire the probe, probedProvider would stay null, and the config fields — gated on draft.probedProvider?.config_schema — would never render at all. #3220's if (draft.probedProvider) return; guard doesn't have that failure mode and is the better fix.

What's still additive on top of #3220 is regression coverage: extracting the defaults-merge into a pure applyProbeResult(draft, result) helper so it can be unit-tested, plus three tests (user input survives a probe resolving mid-typing; schema defaults still seed a fresh selection; a user-entered value beats a schema default). I'll offer those to #3220 directly, or send them as a follow-up once it merges.

Thanks @IceRhymers for getting there first.