support official DeepSeek Responses endpoints

[Rat0323]

Problem

Codex++ cannot currently use Codex Code Mode with DeepSeek's official Responses API. Code Mode publishes a custom exec tool, while the official DeepSeek endpoint rejects that tool with Unsupported custom tool: 'exec'.

This affects both the built-in DeepSeek preset and manually configured suppliers that point to the same official Responses endpoint. Treating the preset as the compatibility boundary would leave equivalent custom configurations broken.

Design

Add provider capability handling at the configuration boundary. The DeepSeek adapter is selected when the active provider resolves to:

wire_api = "responses"
base_url = "https://api.deepseek.com/"

Endpoint detection uses the effective host (deepseek.com or a subdomain), not the preset ID, provider name, or model name. Values in the configuration being saved take precedence over stale profile fields.

For matching configurations, Codex++ disables Code Mode while preserving Unified Exec:

[features]
code_mode_only = false

[features.code_mode]
enabled = false

Unified Exec remains available through the supported exec_command and write_stdin function tools. Existing feature tables, including inline tables, retain unrelated settings.

Endpoint-based detection keeps the workaround scoped to the capability that requires it:

• third-party relays retain their own Responses tool behavior instead of inheriting restrictions from the model name
• Chat Completions continues through the existing protocol-proxy path and does not publish the failing Responses custom tool
• other Responses providers retain their existing capability handling

Model catalog

Add bundled metadata for the official DeepSeek Responses models:

• expose deepseek-v4-flash and deepseek-v4-pro in the default preset, keeping Flash as the default
• mark both official models with supported_in_api = true
• use a 1,048,576-token context window with a 95% effective context window
• set tool_mode = null and supports_search_tool = false
• preserve explicit user-provided model_catalog_json values

Applying a matching supplier profile generates this metadata for supported deepseek-v4-* entries. Direct config-file saves apply the compatibility transform without generating a catalog when profile and model-list context is unavailable.

CI prerequisite

Include the line-ending normalization from #1735. The upstream asset checks otherwise depend on checkout line endings and can fail before validating this change.

Validation

• cargo test -p codex-plus-core --test relay_config --locked -- --test-threads=1 (122 passed)
• cargo test -p codex-plus-core --test model_suffix --locked -- --test-threads=1 (15 passed)
• cargo test -p codex-plus-core --lib --locked -- --test-threads=1 (214 passed)
• npm test in apps/codex-plus-manager (55 passed)
• live /models verification lists both deepseek-v4-flash and deepseek-v4-pro
• live deepseek-v4-pro Responses request completed successfully
• live Flash and Pro requests still reject custom exec with Only 'apply_patch' is supported
• git diff --check

References

• https://api-docs.deepseek.com/guides/responses_api/
• https://api-docs.deepseek.com/api/create-response/
• https://api-docs.deepseek.com/quick_start/agent_integrations/codex/
• https://api-docs.deepseek.com/news/news260813/
• fix(ci): keep upstream theme assets LF-normalized #1735

[BigPizzaV3]

维护者合并进度：#1735、#1746、#1733、#1718、#1771 等基础修复已进入 main；本 PR 现在与最新 main 在 apply_model_catalog_to_config 产生真实冲突，因此本轮暂未强制合并。

rebase 时需要同时保留两边语义，建议按以下顺序组合：

1. 同时初始化 official_deepseek_responses 和可变的 config_text。
2. 若现有 model_catalog_json 是已知的 cc-switch catalog，先移除该指针并继续生成 Codex++ 管理的 DeepSeek catalog。
3. 若它是真正的用户自定义 catalog，官方 DeepSeek Responses 模式仍按本 PR 语义保留并直接返回。
4. 非官方 DeepSeek 模式继续沿用现有 custom Responses catalog 复制逻辑。
5. live_external_model_catalog 的继承只在非官方 DeepSeek 模式执行。

也就是说，cc-switch catalog 不应被“preserve explicit user catalog”误判为用户 catalog；但其它用户自定义路径仍必须保留。请 rebase 到最新 main、按上述边界解决 .gitattributes 与 relay_config.rs 冲突并重跑三平台 CI，通过后即可继续合并。

[BigPizzaV3]

复审发现一处 catalog 能力判断边界，建议合并前修正：apply_deepseek_responses_compatibility 通过 uses_official_deepseek_responses_for_config(profile, config_text) 优先读取最终配置中的 active provider；但 apply_model_catalog_to_config 仍通过 uses_official_deepseek_responses(profile) 读取 profile 的 base_url/upstream_base_url。

当 profile 残留 api.deepseek.com，而实际 config.toml 已改为第三方 Responses provider 时，Code Mode 会正确保留，但 catalog 仍可能按官方 DeepSeek 元数据生成，两条能力判断不一致。建议 apply_model_catalog_to_config 同样基于最终 config_text 调用 uses_official_deepseek_responses_for_config，并补回归测试，断言该场景保留第三方 catalog 的 effective_context_window_percent = 100 与 Code Mode。其余 rebase 边界和三平台 CI 当前均正常。

[Rat0323]

已按复审意见更新，提交为 7941ba4：

1. apply_model_catalog_to_config 现在同样基于最终 config_text 调用 uses_official_deepseek_responses_for_config，不再仅依赖可能过期的 profile URL。
2. 新增 stale DeepSeek profile + third-party Responses 回归测试，确认 Code Mode 保持启用，生成 catalog 的 effective_context_window_percent = 100。
3. 根据 DeepSeek 2026-08-13 V4-Pro GA 公告，将 deepseek-v4-pro 标记为 API 可用并加入默认预设模型列表，默认模型仍为 Flash。
4. 使用官方 API 实测：/models 同时返回 Flash 和 Pro，Pro Responses 请求可正常完成；Flash 和 Pro 仍会拒绝自定义 exec，返回 Only 'apply_patch' is supported，因此现有 Code Mode 兼容开关仍有必要。

验证结果：

• relay_config: 122 passed
• model_suffix: 15 passed
• codex-plus-core --lib: 214 passed
• manager npm test: 55 passed
• git diff --check: passed

请复审。