Setting provider.<id>.options.baseURL changes which model opencode picks by default

Summary

Adding a provider.<id> block to opencode.json — even one that only sets
options.baseURL, with no credential and no model named — promotes that provider
into the configured set and changes which model opencode picks by default. For a
user who has no credential for that provider, a working opencode stops working.

This is surprising because setting a base URL reads as "if I use this provider,
send it here", not "use this provider".

Reproduction

opencode 1.18.27, macOS (arm64). Two runs, each with a fresh HOME and a
scratch OPENCODE_CONFIG, differing only in the config file. In both,
OPENAI_API_KEY is set and there is no Anthropic credential anywhere.

A — baseline

{ "$schema": "https://opencode.ai/config.json" }

$ opencode run "say hi"
> build · gpt-5.3-chat-latest
Error: Incorrect API key provided: probe-openai. ...

Model selection is correct: it picks an OpenAI model, and the request reaches
OpenAI. (The key is deliberately invalid; the point is where the call went.)

B — one base URL added

{
  "$schema": "https://opencode.ai/config.json",
  "provider": { "anthropic": { "options": { "baseURL": "http://127.0.0.1:8899/anthropic/v1" } } }
}

$ opencode run "say hi"
> build · claude-sonnet-4-6
Error: Anthropic API key is missing. Pass it using the 'apiKey' parameter or the ANTHROPIC_API_KEY environment variable.

The default model flipped to an Anthropic one and the run fails. The flip
happens before any network call, so it is not the loopback URL being
unreachable — it is the block existing.

Not specific to Anthropic

The same pair with the built-in nearai provider, again with OPENAI_API_KEY
only and no NEARAI_API_KEY:

config	model chosen
empty	gpt-5.3-chat-latest
provider.nearai.options.baseURL set	google/gemini-3-pro

So it is the presence of any provider.<id> block that reorders selection, not
something about a particular provider.

Also affects a provider the user does use

Worth stating for completeness, because this half works exactly as documented:
with an Anthropic credential present, adding the same baseURL correctly
redirects. A probe server on the configured base logs the call arriving:

HIT POST /anthropic/v1/messages host=127.0.0.1:8899

So the redirect behaviour is right. It is only the coupling to provider
selection that is surprising.

Why it matters beyond a surprising default

Anything that configures opencode on a user's behalf — a proxy's setup command,
a corporate config template, a devcontainer — has no safe way to set a base URL.
Writing the key is correct for a user of that provider and breaks a user who is
not, and the two are indistinguishable from outside.

Suggested directions

Any one of these would resolve it; I have no attachment to which:

1. Do not let a provider.<id> block that supplies no credential and no models
   affect default model selection — treat options.baseURL as configuration
   for a provider rather than an election of it.
2. Rank a provider the user has a credential for above one that only has
   options set.
3. If the coupling is intentional, documenting it on the provider.options
   field would be enough — the schema description ("Custom provider
   configurations and model overrides") does not currently hint at it.

Happy to send a PR if you can say which direction you would take.