feat(web): add Z.AI and BigModel native search (rescue of #5685)

[Hmbown]

Summary

• Current-main rescue of feat(web): add Z.AI and BigModel native search #5685 by h3c-hexin (fork pushes to the PR branch were denied 403, so the reconciliation merge lives here). Both original commits and authorship are preserved verbatim; this PR adds only the merge with current main and conflict resolution where the DeepSeek (feat(web): add DeepSeek native search adapter #5683) and Qwen (feat(web): add Qwen native search adapter #5684/feat(web): add Qwen native search adapter (rescue of #5684) #5690) adapters landed in the same hunks.
• Enable structured provider-native search on the exact Z.AI global and Zhipu China general API products for documented GLM models.
• Select search-prime for api.z.ai and search_std for open.bigmodel.cn; Coding Plan, neighboring paths, and custom-compatible endpoints remain fail-closed.
• Classify the existing open.bigmodel.cn/api/paas/v4 configuration as part of Z.AI's official endpoint family so model aliases and credential scope use the existing Z.AI identity.

Reconciliation notes: the adapter's provider gate now admits Openai, Anthropic, Xai, Zai, ModelStudio Token Plan, DeepSeek, and DeepSeek-CN together; route capability arms and tests from all three sibling slices coexist; both changelog entries retained and regenerated in sync.

No-Issue: partial delivery tracked by #5681; this slice must not close the umbrella issue.
Supersedes #5685 (which stays credited to h3c-hexin).

[claude]

Claude finished @Hmbown's task in 2m 59s —— View job

---

Claude's review of PR #5691

Todo list

• Gather context (diff, changed files, CLAUDE.md/AGENTS.md rules)
• Review correctness (logic, panics, error handling)
• Review provider/model/route safety (EPIC v0.8.65 EPIC: Separate provider facts, model facts, offerings, and route resolution #2608 invariant)
• Review reuse/simplification
• Review test coverage
• Review security
• Post final review summary

Summary

This is a clean, well-scoped rescue of #5685: it wires structured Z.AI/Zhipu web search behind an exact base-URL allowlist (api.z.ai/api/paas/v4 → search-prime, open.bigmodel.cn/api/paas/v4 → search_std), keeps the Coding Plan endpoint and any custom-compatible endpoint fail-closed, and reuses the existing citation/URL-validation plumbing rather than reimplementing it. I traced the merge conflict resolution against origin/main and found no dropped test cases, no duplicate match arms, and no leftover conflict markers anywhere in the tree.

Correctness

• crates/tui/src/client/provider_native_search/zai.rs:9-14 — build_body normalizes and matches base_url against the two exact official general-API hosts and bail!s otherwise; the Coding Plan and any gateway/custom host correctly fall through to an error rather than silently sending a request.
• crates/config/src/route/resolver.rs:243-253 — the new ProviderKind::Zai block runs after the existing custom-endpoint capability reset, and documented_zai_web_search_for_route independently re-checks the exact base URL, so a custom/gateway Zai endpoint can't accidentally inherit Supported even though the block is unconditional. Verified this doesn't regress the pre-existing custom-endpoint fail-closed guarantee.
• provider_native_search.rs:94-101 — maximum_domain_count() falls through to Some(0) for Zai (same as the existing Deepseek/ModelStudio arms), so a caller-supplied domains filter is rejected explicitly by tools/web/backend.rs:351-358 with an actionable error instead of zai::build_body silently dropping it. This matches existing precedent for the other Responses-style adapters that don't support domain filters — not a new gap introduced by this PR.
• All three provider dispatch match blocks in provider_native_search.rs (body build, URL, response parse) add the Zai arm consistently; no arm was missed.

Provider/model/route safety (EPIC #2608)

• No inference is made from a model-string prefix. The web-search fact is gated on ProviderKind::Zai (explicit provider selection) and an exact base-URL match, and the model id is only used to look up the wire-level allowlist in documented_server_side_web_search. This is consistent with the sibling DeepSeek/Qwen slices already in the branch.

Reuse/simplification

• Good reuse: zai::parse and zai::build_body route through the shared citation_from_url/push_citation helpers (URL scheme/host validation included) instead of duplicating citation normalization.

Tests

• Coverage looks adequate for the new surface: unit tests in zai.rs cover both official engines and the coding-endpoint rejection; capabilities.rs and route/tests.rs cover the exact-vs-adjacent-endpoint fail-closed behavior at the route-resolution layer; config/src/tests.rs covers the official-endpoint-family classification. No gaps identified.

Minor nit (non-blocking)

• crates/config/src/route/capabilities.rs:56 — the Zhipu doc-source link contains raw non-ASCII characters inside a bare <...> autolink (<https://docs.bigmodel.cn/api-reference/工具-api/网络搜索>). CommonMark autolinks are technically ASCII-only, so some renderers may show this as literal text rather than a link. Cosmetic only, doesn't affect compilation or behavior — feel free to leave as-is or percent-encode.

No blocking issues found. Nice work keeping the fail-closed boundary exact on both the adapter and route-resolver sides.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 198326110b

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

Preserve path case when matching exact Z.AI routes

When a configured URL uses a differently cased path such as https://api.z.ai/API/paas/v4, this lowercasing marks the route as search-capable even though URL paths are case-sensitive. The adapter similarly accepts the normalized value, but api_url retains the original path and posts to /API/paas/v4/web_search, causing a failed request instead of failing closed during route resolution. This also conflicts with the existing exact-route predicate and test in provider.rs, which deliberately reject the uppercase-path form; normalize only the scheme/host while comparing the path exactly.

Useful? React with 👍 / 👎.