fix(providers): align Bailian reasoning capabilities

[ewen-poch]

Problem

The merged Bailian providers hid documented reasoning controls and treated Responses support too broadly for standard Bailian. Bailian for Plan must remain on its documented Anthropic and OpenAI-compatible Chat surfaces rather than being advertised as Responses-compatible. Qwen 3.8 also used the rounded 1M context value instead of the 983,616-token Codex integration limit.

Proposed change

• Add a low / medium / xhigh reasoning preset for Qwen 3.8 Max and Preview.
• Expose high / max for the documented GLM 5.2 and DeepSeek V4 Chat models.
• Route Responses at model level for standard Bailian's documented Qwen subset, while Bailian for Plan does not advertise Responses support.
• Set Qwen 3.8 Max and Preview context windows to 983,616 tokens.
• Add focused coverage for every changed model capability and preserve exact catalog metadata coverage.

Official references:

• https://help.aliyun.com/zh/model-studio/compatibility-with-openai-responses-api
• https://help.aliyun.com/zh/model-studio/qwen-api-via-openai-chat-completions
• https://help.aliyun.com/zh/model-studio/anthropic-api-messages
• https://help.aliyun.com/zh/model-studio/codex
• https://bailian.console.aliyun.com/cn-beijing?tab=doc#/doc/?type=model&url=2841718

Scope and non-goals

This is a provider capability metadata correction. It does not change architecture, persistence schemas, data relationships, or endpoint construction. Qwen 3.7/3.6 remain conservative in the cross-protocol reasoning selector because their documented Chat controls are protocol-specific and do not fit the current model-wide effort seam.

Acceptance criteria and validation

All commands below ran after the final edit:

• Standard Bailian's Responses allowlist, Bailian for Plan's unsupported Responses status, reasoning profiles, catalog metadata, and Qwen 3.8 context -> npm test -- src/shared/provider-registry.test.ts src/shared/reasoning-effort.test.ts -> 69 passed.
• Type safety -> npm run typecheck -> passed.
• Repository lint -> npm run lint -> passed with 18 pre-existing warnings outside the changed files; changed files are clean.
• Full regression suite -> npm test -> 697 files and 10,211 tests passed; 15 files and 184 tests skipped by the existing suite.
• Independent standards and specification reviews -> no remaining findings.

Uncovered risk: validation is based on the current official documentation and project-owned tests; no production API-key smoke test was performed, so future provider-side capability changes remain external risk.

Review focus

Please verify the Responses boundary between standard Bailian and Bailian for Plan, plus the distinction between Qwen 3.8's low / medium / xhigh vocabulary and GLM/DeepSeek's high / max vocabulary.

[github-actions]

Codex Review

Verdict: needs changes

[P1] Bailian cannot be added during Codex onboarding

src/shared/provider-registry.ts:233

Impact: Bailian now advertises only Anthropic and Chat Completions at the vendor level, while its Responses-capable Qwen models are listed separately. Provider onboarding checks this vendor-level endpoint list, so Codex rejects Bailian—even though the default qwen3.8 model supports Responses. The picker also treats all models of an inactive Bailian provider as Responses-capable based on the default model.

Recommendation: Make onboarding and renderer model compatibility resolve endpoints for the specific selected/default model using isVendorModelResponsesSupported, or expose per-model endpoint capabilities in the provider view. Keep unsupported Bailian DeepSeek/GLM entries unavailable to Codex.

Summary: Per-model Responses support is added to the registry, but onboarding and model selection still consume vendor-level endpoints. This makes supported Bailian models unusable in some Codex flows and can expose unsupported models as selectable.

[github-actions]

Codex Review

Verdict: mergeable

No actionable findings.

Summary: No concrete merge-blocking defects found in the requested changes. Branch and pull-request title prechecks are valid.