Onboarding cannot configure OpenAI-compatible base URLs or model capabilities

**Describe the bug**

Buzz Desktop onboarding exposes an `OpenAI-compatible` provider and a custom-provider ID, but does not provide a base URL field or a supported way to discover/register that provider’s models and capabilities. A user can enter an API key, yet cannot point Buzz at an OpenAI-compatible gateway during onboarding.

For custom providers, the model-discovery path is disabled, so Buzz cannot learn authoritative endpoint/modality capabilities such as image input or image generation. The practical workaround is to edit environment/runtime configuration inside the isolated `.buzz` environment manually or ask an agent to do it. This turns a supported-looking onboarding option into a partially configured provider that can fail later with misleading or opaque errors.

Current source does include `Skip for now` on the default-model step, so the bug is not the total absence of a skip action. The UX gap is that users who do configure an OpenAI-compatible/custom provider cannot complete the necessary base-URL and capability setup in the same flow.

**Steps to reproduce**
1. Start Buzz Desktop first-run onboarding.
2. Reach “Configure your default model settings.”
3. Choose an available harness and select `OpenAI-compatible`, or choose `Custom provider…`.
4. Observe that the UI accepts provider identity/API-key data but has no base URL field for a gateway such as `https://api.inferencesaver.com/v1`.
5. Observe that custom-provider model discovery/capability registration is unavailable.
6. Complete setup and attempt an image/multimodal request through a custom gateway model.
7. The client cannot validate whether the selected model supports the requested modality; failures may surface only after forwarding, and may then be mislabeled or opaque as described in #5061.

**Expected behavior**
- The onboarding and Settings provider editor should expose a base URL field for OpenAI-compatible providers.
- Buzz should validate the URL, keep credentials secret, and test the provider with authenticated model discovery.
- The provider contract should retain authoritative per-model endpoint/modality capabilities where available, with a clear “unknown” state rather than assuming capability from OpenAI wire shape.
- Model selection and attachment/image controls should gate unsupported operations before dispatch.
- A test-connection result should explain missing auth, unavailable model discovery, missing capability metadata, and payload limits.
- The same configuration should be editable after onboarding without manually changing `.buzz` environment files.

**Version and platform**
- Buzz version: current `main` inspected at `6ca9641a9555e48f99b3ebccc123ca8c25648a45`
- OS: Windows

**Logs / additional context**
- Related error-UX issue: #5061.
- Related configuration/tool visibility issues: #5060, #4852, and #4853.
- Example public OpenAI-compatible gateway starter: https://github.com/matthewdonsemail-lab/inferencesaver-ai-gateway-starter
- InferenceSaver’s OpenAI-compatible base URL is `https://api.inferencesaver.com/v1`; the starter demonstrates environment-only API-key handling and authenticated `/v1/models` discovery.
- [`DefaultConfigStep.tsx`](https://github.com/block/buzz/blob/6ca9641a9555e48f99b3ebccc123ca8c25648a45/desktop/src/features/onboarding/ui/DefaultConfigStep.tsx#L211-L290) requires a selected harness/config validity and renders the shared provider fields. [`DefaultConfigStep.tsx`](https://github.com/block/buzz/blob/6ca9641a9555e48f99b3ebccc123ca8c25648a45/desktop/src/features/onboarding/ui/DefaultConfigStep.tsx#L330-L385) also confirms that `Skip for now` exists.
- [`agentConfigOptions.tsx`](https://github.com/block/buzz/blob/6ca9641a9555e48f99b3ebccc123ca8c25648a45/desktop/src/features/agents/ui/agentConfigOptions.tsx#L109-L119) defines OpenAI/OpenAI-compatible credentials only through `OPENAI_COMPAT_API_KEY`; no base-URL field is defined there.
- [`AgentConfigFields.tsx`](https://github.com/block/buzz/blob/6ca9641a9555e48f99b3ebccc123ca8c25648a45/desktop/src/features/agents/ui/AgentConfigFields.tsx#L312-L372) suppresses provider discovery while editing a custom provider. [`AgentConfigFields.tsx`](https://github.com/block/buzz/blob/6ca9641a9555e48f99b3ebccc123ca8c25648a45/desktop/src/features/agents/ui/AgentConfigFields.tsx#L720-L744) exposes only a “Custom provider ID” text field.

No API keys or credential values are included in this report.

Start with DefaultConfigStep.tsx, agentConfigOptions.tsx, and AgentConfigFields.tsx, then trace how provider configuration and discovery are persisted and used. The work is complete when onboarding and Settings support the required base URL and authenticated discovery, preserve model capability metadata, and clearly report unsupported or unknown capabilities before dispatch.

Written by the indexing model from the issue text.