feat: add OVHcloud AI Endpoints provider support

[aheritier]

Add ovhcloud as a built-in alias provider for OVHcloud AI Endpoints (closes #3342, related #3145).

Users can now write provider: ovhcloud (or inline ovhcloud/Qwen3-235B-A22B) without hand-rolling a custom providers: block.

Highlights

• Free-tier access: OVHcloud offers rate-limited free access to several models including Qwen3-235B-A22B with no billing setup required.
• Fixes Stream silently produces empty response when model outputs non-standard delta.reasoning SSE field (Qwen3 thinking mode) #3145 for the built-in alias: shouldMergeConsecutiveMessages is extended to coalesce consecutive system messages for ovhcloud, exactly as PR feat: add Baseten provider support #3341 did for baseten. Without this, Qwen3 on OVHcloud returns an empty stream when a request carries more than one system message (docker-agent emits one per toolset).
• delta.reasoning already handled: The streaming adapter fix for Qwen3's thinking output (originally noted in Stream silently produces empty response when model outputs non-standard delta.reasoning SSE field (Qwen3 thinking mode) #3145) was made generic in feat: add Baseten provider support #3341 and needs no further changes.
• No oaistream changes: The usage-on-content-chunks fix from feat: add Baseten provider support #3341 is provider-agnostic and already in main.

Files changed (15): alias + auto-detection Go code with full test coverage, provider doc page, nav/concept/config doc updates, example YAML.

Note: The provider page describes the API type as openai_chatcompletions (matching the Baseten docs convention) even though the internal alias field is "openai". This is consistent with all other OpenAI-compatible alias docs and does not affect runtime behaviour.

[Sayt-0]

Summary

The alias plumbing, auto-detection, consecutive system-message merge, docs coverage, and test coverage are all correct and consistent with the Baseten pattern (#3341). One blocking issue: the default model Qwen3-235B-A22B is not present in the current OVHcloud AI Endpoints catalogue, which breaks the out-of-the-box experience the PR advertises.

Model IDs verified against the catalogue

Checked against the live /v1/models endpoint (https://oai.endpoints.kepler.ai.cloud.ovh.net/v1/models) and the official catalogue.

Model referenced	In current catalogue
Qwen3-235B-A22B (default)	no
Qwen3-32B	yes
Meta-Llama-3_3-70B-Instruct	yes
Mistral-Small-3.2-24B-Instruct-2506	yes
Mixtral-8x7B-Instruct-v0.1	no
DeepSeek-R1-Distill-Llama-70B	no

The catalogue appears to have rotated its large Qwen3 MoE from Qwen3-235B-A22B to Qwen3.5-397B-A17B. Other current Qwen3 IDs: Qwen3.6-27B, Qwen3.5-9B, Qwen3-Coder-30B-A3B-Instruct.

Impact

• DefaultModels["ovhcloud"] is what auto-selection returns when only OVH_AI_ENDPOINTS_ACCESS_TOKEN is set, so docker-agent run with just the token requests a nonexistent model and fails.
• examples/ovhcloud.yaml and the doc snippets do not work as written.
• TestParseExamples does not catch this, because ovhcloud was added to modelsDevAbsentProviders, which disables the model-existence check for this provider.

Suggested fix

• Point the default at a model that currently exists, e.g. Qwen3.5-397B-A17B (current large MoE, confirmed working) or Qwen3-32B (lighter, more likely free-tier). Propagate to DefaultModels, examples/ovhcloud.yaml, and the doc snippets.
• Drop or replace the three stale rows in the model table.
• Optional doc improvement: mention provider_opts.enable_thinking: false for Qwen3 to suppress reasoning output, and confirm which model the free tier serves.

Not blocking (correct as-is)

Env var name (OVH_AI_ENDPOINTS_ACCESS_TOKEN), base URL, auto-detection precedence, and the merge path via Provider == "ovhcloud" are all correct. Because the catalogue rotates, pinning any single default is inherently fragile, but the pinned ID should at least exist at merge time.

[Sayt-0]

Qwen3-235B-A22B is not in the current OVHcloud catalogue (not returned by https://oai.endpoints.kepler.ai.cloud.ovh.net/v1/models). This is the model auto-selection returns when only OVH_AI_ENDPOINTS_ACCESS_TOKEN is set, so the token-only path fails at runtime. Suggest an existing ID, e.g. Qwen3.5-397B-A17B (current large MoE) or Qwen3-32B.

[Sayt-0]

Same nonexistent model, so this example fails as written. Suggest Qwen3.5-397B-A17B or Qwen3-32B.

[Sayt-0]

Nonexistent model in the inline example. Suggest an existing ID (e.g. ovhcloud/Qwen3.5-397B-A17B). The Named Model snippet at line 45 has the same issue.

[Sayt-0]

Three of these IDs are absent from the current catalogue: Qwen3-235B-A22B (line 64), Mixtral-8x7B-Instruct-v0.1 (line 68), and DeepSeek-R1-Distill-Llama-70B (line 69). Current options to list instead: Qwen3.5-397B-A17B, Qwen3.6-27B, Qwen3.5-9B, Qwen3-Coder-30B-A3B-Instruct.

[aheritier]

Addressed all review findings in 310a140:

• Default model (auto.go, examples/ovhcloud.yaml, all doc snippets): replaced Qwen3-235B-A22B with Qwen3.5-397B-A17B (confirmed current in the catalogue).
• Model table: dropped the three stale rows (Qwen3-235B-A22B, Mixtral-8x7B-Instruct-v0.1, DeepSeek-R1-Distill-Llama-70B) and added the current catalogue IDs (Qwen3.5-397B-A17B, Qwen3.6-27B, Qwen3.5-9B, Qwen3-Coder-30B-A3B-Instruct).

[Sayt-0]

The changes are correct ! Approving !