desktop: custom provider save always throws "unavailable on this server" #50650

Summary

OpenCode Desktop exposes the "Custom OpenAI-compatible provider" form in Settings → Providers, but the save handler unconditionally throws provider.custom.unavailable, so the flow can never succeed on any server — including the app's own bundled local server.

Environment

• opencode version: Desktop 2.0.14 (bundled opencode-cli v2.0.14, dpkg opencode 2.0.14)
• OS: Ubuntu 26.04.1 LTS, Linux 7.0.0-31-generic, x86_64
• Terminal: Unavailable: this is the Desktop (Electron) UI, no terminal involved
• Shell: /bin/bash
• Install/channel: release .deb downloaded from the Desktop section of https://opencode.ai/v2/docs
• Active plugins: none found in config

Reproduction

1. Install opencode-desktop-linux-amd64.deb (Desktop 2.0.14) and launch OpenCode Desktop.
2. Open Settings → Providers.
3. Select the custom provider entry ("Custom OpenAI-compatible provider").
4. Fill in valid-looking values, e.g. provider ID local, name My Local Server, baseURL http://localhost:8080/v1, model ID my-model.
5. Click Save/Connect.

Expected Behavior

The provider is written to the user config (providers.<id>) and shows up in the model picker — the same result as adding the block to opencode.json manually.

Actual Behavior

Save always fails with the toast: "Custom providers are unavailable on this server" (i18n key provider.custom.unavailable).

The shipped app.asar build shows the mutation is a stub with no server or protocol condition:

mutationFn: async e => {
  throw Error(a.t(`provider.custom.unavailable`))
}

It throws for every server, so the dialog is reachable but unusable.

Additional Context

• Not a server/config problem: adding the provider manually to ~/.config/opencode/opencode.json loads it correctly on the very server the app spawns — GET /api/provider on the bundled server returns {"id":"local","name":"My Local Server","activation":"enabled", ...}. The failure is isolated to the dialog's save path.
• Frequency: 100% reproducible (unconditional code path).
• Current source appears to rework this: the same handler is gated with if ((await serverSDK().protocol) !== "v1") throw ... and the settings entry is wrapped in <Show when={protocol() === "v1"}>, so it looks like the shipped 2.0.14 build predates that change.
• Suggestion: either ship the save implementation in the build, or hide the entry point until it works — the UI currently offers an action that can never succeed.