fix: support keyless openai-compatible endpoints

[kalvinnchau]

Summary

• make the OpenAI-compatible base URL a first-class required field across agent create, edit, defaults, and onboarding surfaces
• preserve a distinct OpenAiCompat runtime provider with an explicit HTTP(S) endpoint and optional API key
• omit bearer authentication from model discovery and inference when the compatible endpoint has no key
• keep official OpenAI key-required and retain its default endpoint behavior

Validation

• full desktop frontend suite: 4,957 tests passed
• full desktop Tauri package: 2,433 tests passed; 15 keychain-only tests ignored
• focused buzz-agent configuration and request-header regression tests passed
• pre-commit formatting, lint, and file-size ratchets passed

Known unrelated failure

The full buzz-agent package still has one MCP cancellation regression that reproduces on current origin/main; the provider-specific runtime tests pass. This PR does not modify that cancellation path.

[themiguelamador]

I found four issues that need to be incorporated before this is ready:

1. The edit dialog's new base-URL validity check ignores the persona env layer for an existing agent that already inherits its harness. Backend readiness accepts the inherited OPENAI_COMPAT_BASE_URL, but the dialog computes compatibleBaseUrlInherited from agent/global/file state only, so Save stays disabled. The fix recognizes persona inheritance while preserving an explicit local blank as a shadow.
2. The persona provider transition still uses the presence of a managed API-key field as proof that discovery requires a key. Selecting openai-compat with no key therefore clears an existing custom model even though this PR makes that key optional. The fix consults the provider's actual required-env-key contract.
3. Desktop readiness treats whitespace-only env values as present, while the runtime trims and rejects the compatible base URL. This reports an agent as ready even though it will fail at launch. The fix aligns Buzz Agent and Goose readiness/file checks with the runtime's blank-value semantics.
4. crates/buzz-agent/README.md still tells vLLM/llama.cpp/Ollama users to select openai, omits openai-compat from the provider list, and documents a default compatible URL rather than the new required explicit endpoint. The fix updates examples, the configuration table, provider matrix, and authentication behavior.

Verified fix: Complear/buzz branch review/pr-5909-fix, commit 9eaf3ac545dff4d1d5b0c6614c43a01326e42380.

Validation: full Desktop frontend suite (4,960 tests), Desktop TypeScript/static/file-size checks, focused Tauri readiness test, full buzz-agent suite, strict buzz-agent clippy, and Rust formatting all pass.

[wpfleger96]

🤖 combined feedback from two independent review passes. Both passes independently confirmed all four issues in the existing review (the inherited-URL gate in the edit dialog, the model-clearing on switch to openai-compat, the untrimmed readiness checks, and the stale buzz-agent README) — treating that convergence as strong confirmation those are real, so not re-litigating them here. The inline comments below are the additional findings that aren't on the PR yet. Also worth noting the branch is currently conflicting with main and needs a rebase.

[wpfleger96]

🤖 I think this creates a silent break for existing records: on main, openai-compat resolves to Provider::OpenAi with the https://api.openai.com/v1 default, but after this change it hard-requires OPENAI_COMPAT_BASE_URL with no default. An agent saved today with provider=openai-compat + key and no base URL works, then flips to NotReady/startup-error after upgrade. There's precedent for boot migrations (the databricks v1→v2 rewrite) — either migrate openai-compat-without-URL records to openai, or call out the intentional break in the PR description.

[wpfleger96]

🤖 now that openai and openai-compat are distinct providers with distinct trust boundaries, they still share OPENAI_COMPAT_API_KEY. Global-defaults env merges into per-agent effective env, and the dialogs deliberately preserve credential env vars across provider switches — so a key configured for api.openai.com gets bearer-sent to whatever custom base URL a compat agent points at. It's pre-existing exposure, but this PR is the moment the providers split, so it feels like the right time to either give compat its own key var or scrub the inherited key unless it was set explicitly for the compat agent. If the shared var is intentional, a note on the accepted risk would do.

[wpfleger96]

🤖 small asymmetry: this now runs validate_openai_compat_base_url on the official openai path too, but runtime Provider::OpenAi still reads the URL via plain env_or with no validation. So discovery rejects a query/fragment URL that inference would happily use. Probably fine to validate both, but as written discovery fails where the runtime works.

[wpfleger96]

🤖 nit: this test mutates process env with set_var without taking the env/path lock other tests in this crate use. The unique key name makes a collision unlikely, but it's inconsistent with the crate's own pattern for env-mutating tests.