fix(providers): route Responses-only models on custom OpenAI providers

[Sayt-0]

Problem

Custom OpenAI-compatible providers declared in the providers: section without
an explicit api_type were hard-defaulted to openai_chatcompletions. Models
that are only served via the Responses API (gpt-4.1, the o-series, gpt-5, Codex)
were therefore sent to /chat/completions and rejected with
400 unsupported_api_for_model — e.g. a github-copilot endpoint declared as a
custom provider running gpt-5.3-codex.

Fixes #2303

Fix

pkg/model/provider/defaults.go

• Added defaultOpenAIAPIType(model): returns openai_responses when
  modelinfo.SupportsResponsesAPI(model) is true, otherwise
  openai_chatcompletions.
• mergeFromProviderConfig now uses defaultOpenAIAPIType(dst.Model) for the
  OpenAI-compatible fallback instead of always setting openai_chatcompletions,
  reusing the same predicate as the built-in routing.

Tests

pkg/model/provider/custom_provider_test.go

• TestApplyProviderDefaults_DefaultsResponsesAPIForNewerModels: a custom
  provider with no api_type routes gpt-5.3-codex, gpt-5, o3-mini to
  openai_responses, while gpt-4o stays on openai_chatcompletions.
• TestApplyProviderDefaults_ExplicitAPITypeWinsOverModel: an explicit
  provider-level api_type is honored even for a Responses-default model.

[docker-agent]

Assessment: 🟡 NEEDS ATTENTION

One medium-severity behavioral regression was confirmed in the changed code.

Summary of findings:

• 🟡 MEDIUM pkg/model/provider/defaults.go:47 — Model-name-based api_type defaulting silently breaks non-OpenAI custom providers whose model names match OpenAI patterns

[docker-agent]

[MEDIUM] Model-name-based api_type defaulting silently breaks non-OpenAI custom providers

defaultOpenAIAPIType now routes any model whose name matches SupportsResponsesAPI prefixes (gpt-4.1*, gpt-5*, codex*, o-series) to openai_responses. This is correct for providers actually pointing at the OpenAI or Copilot API — but the gate that triggers this logic (isOpenAICompatibleProvider(resolveEffectiveProvider(src))) is too broad:

• A custom provider declared with only a base_url and no explicit Provider field resolves its effective type to "openai" (via resolveEffectiveProvider), which makes isOpenAICompatibleProvider return true.
• This means any URL-based third-party gateway (a local vLLM instance, LiteLLM proxy, Azure relay, etc.) that names its model gpt-5-local, o3-preview, or codex-custom will silently have requests routed to /responses instead of /chat/completions, causing 404 or 400 errors.

Before this PR: all custom providers defaulted to openai_chatcompletions — a safe universal default.
After this PR: the default is model-name–driven, and any pattern match sends traffic to /responses.

The workaround exists (api_type: openai_chatcompletions in the provider config), but users have no way to know they need it unless they read the source code.

Suggested mitigation: consider narrowing the condition — e.g., only apply defaultOpenAIAPIType when src.BaseURL contains openai.com or githubcopilot.com, or add a first-class boolean flag (responses_api_routing: true) that operators must opt into for custom providers.