feat(desktop): list a harness's own LLM providers in a searchable picker

[i386]

Problem

In Create agent and Edit agent, choosing the Goose harness offered a built-in
seven-row provider list (Anthropic, OpenAI, OpenAI-compatible, OpenRouter, Buzz shared
compute, Databricks, Databricks v2) plus a Custom provider… free-text box.

Goose itself knows ~85 providers (Amazon Bedrock, Ollama, Together AI, LiteLLM, Groq,
xAI, …). Everything outside Buzz's hardcoded shortlist could only be reached by typing a
raw provider id into the free-text box, where a typo fails silently at launch. It also
means each new provider has to be hand-added per release (see #3055, #4133).

Goose already publishes its own inventory over the ACP custom request
_goose/unstable/providers/list, so the list does not need to be hardcoded at all.

Change

When the selected harness advertises that it publishes a provider inventory, the
LLM-provider control is populated from the harness and becomes a searchable combobox
instead of a menu:

• Search over provider name and provider id, so a 85-row list stays usable.
• Harness rows are appended after the built-in ones, de-duplicated by id, in the
  harness's own order, and keep the raw id as the value (that id is what lands on
  GOOSE_PROVIDER — a prettified value would select a provider goose cannot resolve).
• Rows goose already has credentials/configuration for are marked Configured.
• Custom provider… stays as the escape hatch.

Wiring, from the harness up:

Layer	Change
crates/buzz-acp	new buzz-acp providers [--json] subcommand: spawn → initialize → _goose/unstable/providers/list → normalized JSON. Adapters without the extension answer -32601, which is treated as "no inventory", not an error. No session is created, so the probe never resolves the provider it is reporting on.
crates/buzz-acp/src/acp.rs	AcpClient::goose_list_providers + the method constant.
desktop/src-tauri	KnownAcpRuntime/AcpRuntimeCatalogEntry gain provider_inventory (goose: true). New discover_agent_providers Tauri command; the spawn/env/PATH/redaction layering is factored out of model discovery into run_agent_helper_command so both probes see exactly the environment a launched agent would (definition env below user env, baked floor applied).
desktop/src/features/agents/ui	useAgentProviderDiscovery (only asks harnesses whose catalog entry sets provider_inventory, so nothing else pays a subprocess spawn), withDiscoveredProviderOptions, and ProviderSelectField, which renders the searchable PersonaModelCombobox for inventory harnesses and the existing compact menu otherwise.

Failure behaviour is deliberately boring: a failed probe or an adapter without the
extension degrades to exactly the previous static list, and searchable is only true when
the harness advertises an inventory — so buzz-agent, Claude and Codex are unchanged and
do not spawn a probe to learn that.

What it looks like (mock bridge, Playwright)

Goose selected in Add agent → Customize for this agent, captured by
goose-provider-picker.spec.ts:

1. the provider field is a searchable combobox (Search providers…) rather than a menu;
2. below the built-in rows the harness's own rows appear — Amazon Bedrock —
   Configured, Ollama, Together AI (none of these are in the built-in catalog) —
   and then Custom provider…;
3. typing oll filters 40-odd rows down to Ollama.

The spec writes those three PNGs to
desktop/test-results/screenshots-goose-provider/ on every run.

Tests

• desktop/src-tauri/src/commands/agent_llm_providers_tests.rs — entry normalization:
  field mapping, configured/acp flags, blank-id rows dropped, and a harness with no
  inventory still returning a valid empty response.
• desktop/src/features/agents/ui/providerInventoryOptions.test.mjs — append/dedupe/order,
  raw id preserved, Configured description, blank ids dropped, base list not mutated.
• desktop/tests/e2e/goose-provider-picker.spec.ts — goose lists harness providers the
  built-in catalog does not have, the control filters, and a harness without an
  inventory keeps the plain menu (no combobox, no search field). Runs in the smoke
  project and produces the screenshots above.
• desktop/tests/e2e/edit-agent.spec.ts — updated to pick goose providers through the
  combobox.

Locally: cargo test -p buzz-acp 1055 passed / 0 failed; cargo test -p buzz-desktop --lib
3439 passed / 0 failed; pnpm test 6833 passed (plus the 7 jsdom failures on
src/features/communities/* that reproduce unchanged on this machine's pristine
main — Node 26 localStorage semantics, unrelated to this diff); pnpm check clean;
pnpm typecheck clean.

The full smoke Playwright project on this machine finished 1440 passed / 1 skipped /
36 failed in 56 min. Re-running those 36 by title against pristine main and against this
branch gives the same result on both — 8 failed / 28 passed (composer caret formatting ×5,
attachment upload progress, own-avatar, project conversation load failure) — so those 8 are
pre-existing on this machine and the rest are load flakiness in a long single-worker run.
Nothing in the provider/model path fails on either tree.

Manually

1. Settings → Agents → Create agent → Customize for this agent → harness Goose.
2. Open LLM provider: the list is searchable and includes providers outside Buzz's
   built-in set; providers goose is configured for say Configured.
3. Pick one and save — the raw provider id is what is persisted for GOOSE_PROVIDER.

Follow-ups (not in this PR)

• Only goose implements the extension today; provider_inventory is a per-harness
  catalog flag, so another adapter can adopt it without touching the UI.
• The inventory is fetched when the dialog opens; it is not cached across dialog opens
  (each open is one short-lived buzz-acp providers probe).

[github-actions]

🔐 Codex Security Review

Status: review required for the current range.

The current range is 845fc16ebf5ec84f87a94ceaf69bb79c004b3a76...d3c7df83211e8bb02d23f93bf7680a3d55f1c106.
A new review must complete for this exact range. When manual authorization
is required, a user with write access must comment exactly
@buzz-security-review d3c7df83211e8bb02d23f93bf7680a3d55f1c106 to authorize a new review.
Any previous review applies only to its recorded range.