test(codex): guard versioned probe endpoints

Follow-up audit: the /v1 insertion bug was not limited to Zhipu /v4. Other Codex presets such as Volcengine Agentplan, BytePlus, and DouBaoSeed use non-/v1 versioned roots like /api/coding/v3 or /api/v3, so old protocol probing would also derive /v3/v1/... paths.

Changes: added representative v3 probe URL regression coverage and recorded the scope in project memory. Normal /v1-ended providers were already handled by the previous branch and are not part of this bug.

Verification: cargo test --manifest-path src-tauri/Cargo.toml probe_url --lib; cargo fmt --manifest-path src-tauri/Cargo.toml --check; git diff --check.

Author: BigStrongSun

memory.md

@@ -3,6 +3,7 @@
 ## 2026-06-30 Codex GLM Model Context and Probe Guidance
 
 - 2026-07-01 用户用智谱 GLM key 实测“测试 Chat / Responses 全不通”时，真实网络和 key 都正常：`https://open.bigmodel.cn/api/paas/v4/chat/completions` 与 `https://open.bigmodel.cn/api/coding/paas/v4/chat/completions` 能返回 200，`/api/paas/v4/models` 和 `/api/coding/paas/v4/models` 也能返回模型列表；失败的 UI 报错路径是 `.../api/coding/paas/v4/v1/chat/completions` / `.../v4/v1/responses`，根因是新加的协议探测 URL 构造没有复用 `/models` 的版本段规则。修复边界：`probe_codex_responses_for_config` / `probe_codex_chat_for_config` 对已以 `/vN` 收尾的 Base URL 直接拼 `/responses` / `/chat/completions`，避免再追加 `/v1`；智谱仍只有 Chat Completions 路径可用，Responses 路径按官方当前接口返回 404，应由 UI 标为 Chat 可用而不是“全不通”。
+- 2026-07-01 同类 URL 风险不只智谱：Codex 预设中火山 Agentplan `https://ark.cn-beijing.volces.com/api/coding/v3`、BytePlus `https://ark.ap-southeast.bytepluses.com/api/coding/v3`、DouBaoSeed `https://ark.cn-beijing.volces.com/api/v3` 也属于“非 `/v1` 版本化根地址”，旧协议探测会错拼成 `/v3/v1/...`。普通以 `/v1` 收尾的供应商旧逻辑已经能直接拼 endpoint，不属于这次 bug。回归测试要同时覆盖 `/v4` 智谱和 `/v3` 火山/豆包代表路径。
 - 2026-07-01 Codex provider 的“测试 Chat / Responses”不能只在按钮旁显示一条错误摘要；真实问题是每个模型可能有不同协议能力。`CodexFormFields` 的探测结果应按模型保存并在“模型映射”每行显示小 tag：`双协议`、`Responses`、`Chat`、`不可用`，tag title 保留 Responses/Chat 详细返回。汇总文案要列出双协议通过、仅 Responses、仅 Chat、双协议失败的模型，避免用户只看到第一个失败模型（如 `glm-4.5`）而不知道其它模型状态。
 - 2026-07-01 “下一步”必须由真实探测结果驱动而不是模型名启发式：双协议通过和仅 Responses 通过的模型进入 Responses provider，只有 Chat 通过的模型进入 Chat provider，双失败模型不进入拆分建议。拆分成两个 provider 只在新增 provider 场景有 `onProviderSplitSuggestionChange` 回调时弹确认框；编辑已有 provider 时只显示行级协议 tag 和汇总，不弹一个确认后无实际保存效果的拆分对话框。
 - 2026-06-30 复查用户提供的智谱 Coding Plan key 后确认：`https://open.bigmodel.cn/api/coding/paas/v4/models` 当前返回的 GLM 条目只有 `id/object/created/owned_by`，没有 `context_window`、`max_context_length` 等规格字段；因此自动获取模型列表若要补齐 GLM 上下文，不能只靠 `/models`。官方 Mintlify 文档提供稳定 markdown：`/cn/guide/start/model-overview.md` 的模型表给出 GLM-5.2 `1M`、GLM-5.1/5/5-Turbo/4.7/4.6 `200K`、GLM-4.5-Air `128K`，单模型页如 `/cn/guide/models/text/glm-4.5.md` 给出 GLM-4.5 `128K`。后端 `model_fetch.rs` 的正确策略是：先解析 `/models` 显式 metadata；若智谱/Z.AI endpoint 的 GLM 模型缺上下文，再从官方 docs markdown 补齐，且只填缺失值、不覆盖上游显式值。

src-tauri/src/commands/model_fetch.rs

@@ -387,6 +387,18 @@ mod tests {
         );
     }
 
+    #[test]
+    fn probe_urls_respect_volcengine_v3_base_urls() {
+        assert_eq!(
+            build_chat_probe_url("https://ark.cn-beijing.volces.com/api/coding/v3", false).unwrap(),
+            "https://ark.cn-beijing.volces.com/api/coding/v3/chat/completions"
+        );
+        assert_eq!(
+            build_responses_probe_url("https://ark.cn-beijing.volces.com/api/v3", false).unwrap(),
+            "https://ark.cn-beijing.volces.com/api/v3/responses"
+        );
+    }
+
     #[test]
     fn probe_urls_preserve_non_v1_full_endpoints() {
         assert_eq!(