fix(desktop): let Goose agents use OpenAI-compatible provider URLs

[BradGroux]

Addresses the Buzz-to-Goose runtime boundary in #2749. The structured base-URL UI remains in #3798.

What was happening

Goose already supports OpenAI-compatible providers when they are configured in Goose itself. The broken path is narrower: Buzz-managed Goose configuration can launch goose acp with a legacy endpoint URL in GOOSE_PROVIDER, or keep Buzz's canonical OPENAI_COMPAT_* values separate from the runtime variables Goose reads. That makes otherwise valid Buzz settings fail before or during model discovery.

What changes

• Keep this PR focused on the Buzz-to-Goose runtime boundary; it no longer changes Buzz Agent configuration or provider UI.
• Map openai-compat and valid legacy HTTP(S) provider values to GOOSE_PROVIDER=openai.
• Mirror the canonical key and base URL into current Goose variables (GOOSE_PROVIDER__API_KEY and GOOSE_PROVIDER__HOST) and the supported OpenAI aliases (OPENAI_API_KEY, OPENAI_HOST, and OPENAI_BASE_URL).
• Normalize aliases inside each configuration layer before merging, so global, persona, and agent precedence stays consistent regardless of which spelling is used.
• Apply the same effective mapping to readiness, saved and unsaved model discovery, spawn, and spawn hashing.
• Reject credential-bearing, query-bearing, fragment-bearing, or invalid HTTP(S) endpoint values before persistence.

#3798 remains the owner of structured OpenAI-compatible Base URL UI. This PR does not duplicate that work.

Verification

Verified on exact head bbf31271ea22cddebcead0bde60457818b13a580, rebased onto current main at b1b283cd4c7f926e12eeee8ae1f38c7471922b16:

• Desktop static checks, formatting, and file-size ratchet passed.
• Full Desktop JavaScript suite passed: 3,885 tests, 0 failures.
• Desktop production build passed.
• Tauri cargo check passed.
• Full Tauri suite passed: 2,063 library tests and 3 mixer diagnostics, 0 failures, 14 ignored keychain/relay tests.
• Strict Tauri Clippy passed with warnings denied.

No third-party credential or live remote endpoint was used. The regression coverage verifies the effective environment and discovery inputs Buzz produces for Goose; it does not claim packaged-GUI or Windows validation.

Scope

This changes only OpenAI-compatible provider translation for Goose. It does not change Buzz Agent provider behavior, add a dependency, or add overlapping configuration UI.

[BradGroux]

I rebuilt this branch on current main rather than force-merging the old implementation through four overlapping runtime refactors.

The issue is still real: Buzz's canonical OpenAI-compatible settings and the environment Goose expects can diverge across readiness, model discovery, and spawn. However, #1968, #2773, #2974, and #3093 changed the correct integration seam. The refreshed implementation uses runtime metadata plus the current effective descriptor so every consumer gets the same provider alias and environment mapping.

Head 484f7e4518202434e6e91c76deb5bdd6fa555ec8 keeps openai-compat as the stored provider identity, supplies Goose's openai backend and runtime-native key/base-URL variables, preserves alias-aware global/persona/agent precedence, and remains compatible with legacy records that stored the endpoint in provider. The UI now separates the provider from its base URL and rejects credential-bearing, query-bearing, fragment-bearing, or non-HTTP(S) endpoints before save.

Verification includes all 3,725 Desktop JavaScript tests, Desktop typecheck, targeted Biome checks, native managed-agent tests, and strict native Clippy. No live third-party endpoint or credential was used, so the proof is the effective environment/discovery contract rather than a remote-provider smoke test.

[yashrajd]

AFAICT you can already configure and use openAI-compatible providers in Goose. And Goose is wired up with Buzz already when you install (at least i didn't manually configure anything for it). So if your openai-compat provider is setup with Goose it will already work in Buzz (screenshot below)

#2827 is about enabling the openai-compatible provider in Buzz harness (not Goose or any other), just some wiring and UI stuff – this AFAICT is still missing.

[BradGroux]

Thanks for the correction. You're right that Goose itself already supports OpenAI-compatible providers, and #2827 is the right place for Buzz Agent/onboarding Base URL UI.

The remaining bug in #2749 is narrower: when the provider is configured through Buzz, especially for legacy records that stored the endpoint URL as the provider, Buzz can launch Goose with that URL in GOOSE_PROVIDER and without translating OPENAI_COMPAT_* settings into the variables Goose reads.

I've rebased and narrowed this PR to that Buzz-to-Goose boundary. The overlapping Buzz Agent/UI changes are gone. Head 36629940a53ebd4c2568623103e1e9de999b857e maps the Buzz configuration to GOOSE_PROVIDER=openai, current GOOSE_PROVIDER__HOST/GOOSE_PROVIDER__API_KEY, and the supported OpenAI aliases while preserving legacy records.

The full Tauri suite now passes with 1,889 library tests plus 3 mixer diagnostics, strict Clippy is clean, and the Desktop checks/build and 3,781-test JavaScript suite pass.

[BradGroux]

Rebased this branch onto current block/buzz main at c55e421a0.

Head moved from 36629940a to e64037835. The only manual integration was in the agent configuration contributor rules: the newly landed shared-agent access rule remains rule 11, and this PR's provider-translation rule is retained as rule 12. The runtime translation implementation itself is unchanged.

Verification:

• Tauri compile check passed.
• Tauri tests passed: 1,889 library tests plus 3 mixer diagnostics; 14 keychain/relay-dependent tests remained explicitly ignored.
• Strict Tauri Clippy passed with all targets and warnings denied.
• git diff --check, DCO trailer checks, and the direct merge-base audit passed.

GitHub checks are rerunning on the new head.

[BradGroux]

Rebased onto current main at b1b283cd4c7f926e12eeee8ae1f38c7471922b16 and re-audited this against #2749 and the current competing PR landscape.

The remaining change is still needed, but its boundary is narrower than the original issue: #3798 owns the structured base-URL UI, while this PR fixes the Buzz-to-Goose runtime translation for Buzz-managed and legacy settings. #3398 only aliases the API key and does not cover endpoint translation or the runtime paths here.

The rebase also tightened the implementation after a clean-context review:

• Ordinary openai configuration no longer inherits a stale compatibility host.
• Provider values and custom endpoint URLs are normalized before precedence is applied.
• Legacy records no longer block unrelated saves; validation happens at the create/update and publication boundaries instead.
• Custom harness aliases remain available without being rejected by generic OpenAI-compatible validation.

Exact-head verification on bbf31271ea22cddebcead0bde60457818b13a580:

• Desktop static checks, typecheck, formatting, and file-size ratchet passed.
• Full Desktop JavaScript suite: 3,885 passed, 0 failed.
• Desktop production build passed.
• Tauri cargo check passed.
• Full Tauri suite: 2,063 library tests plus 3 mixer diagnostics passed, 0 failed, 14 ignored.
• Strict Tauri Clippy passed with warnings denied.

No packaged-GUI or Windows validation was performed; the regression coverage verifies the effective environment and discovery inputs Buzz produces for Goose.