feat(web): add Qwen native search adapter (rescue of #5684)

[Hmbown]

Summary

• Current-main rescue of feat(web): add Qwen native search adapter #5684 by h3c-hexin (fork pushes to the PR branch were denied 403, so the reconciliation merge lives here). All three original commits and authorship are preserved verbatim; this PR only adds the merge with current main and the conflict resolution where feat(web): add DeepSeek native search adapter #5683's DeepSeek adapter landed in the same hunks.
• Enable provider-native web search for qwen3.8-max, qwen3.7-plus, and qwen3.7-max on ModelStudio Token Plan's Responses Harness.
• Send the documented web_search tool with string tool_choice: "required" through the active authenticated transport.
• Keep preview, Coding Plan, Anthropic, and custom-compatible routes fail-closed.

Reconciliation notes: provider_native_search.rs and route/capabilities.rs now carry both the DeepSeek (#5683) and ModelStudio arms; both changelog entries retained; crates/tui/CHANGELOG.md regenerated in sync.

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

[claude]

Claude finished @Hmbown's task in 3m 25s —— View job

---

Review: Qwen native search adapter (rescue of #5684)

• Gather context (diff, changed files, related route/capability code)
• Understand request (code review)
• Review correctness bugs
• Review provider/model/route safety invariant (EPIC v0.8.65 EPIC: Separate provider facts, model facts, offerings, and route resolution #2608)
• Review reuse/simplification opportunities
• Review test coverage
• Review security concerns
• Post final review summary

Summary

This is a clean, well-scoped port of the DeepSeek native-search pattern to Qwen on ModelStudio Token Plan. I read the full diff (git diff origin/main...HEAD) and traced the capability-gating chain end-to-end; I could not execute cargo test/cargo build in this sandbox (commands require approval this session), so verification is from static reading only — worth a manual cargo test -p codewhale-config -p codewhale-tui before merge if that hasn't run in CI yet.

Provider/model/route safety (EPIC #2608) — looks correct. This is the part I scrutinized hardest given the reconciliation with #5683's DeepSeek arms in the same hunks:

• documented_server_side_web_search("modelstudio-token-plan", model) (crates/config/src/route/capabilities.rs:79-82) is an explicit provider+model tuple lookup, not a prefix/name inference — qwen3.7-plus/qwen3.7-max/qwen3.8-max are enumerated exactly, qwen3.8-max-preview and any DeepSeek/GLM model resold under ModelStudio correctly fall through to Unknown.
• Fail-closed for Coding Plan and the Anthropic dialect is enforced twice, independently: (1) the capability lookup only fires for the "modelstudio-token-plan" string, and (2) ProviderNativeSearchClient::new (crates/tui/src/client/provider_native_search.rs:45-56) only matches ApiProvider::ModelstudioTokenPlan, not ModelstudioTokenPlanAnthropic or ModelstudioCodingPlan (separate enum variants, confirmed in crates/tui/src/config.rs). Belt-and-suspenders, no gap.
• Custom/alternate base URLs (coding-intl..., .../apps/anthropic, arbitrary compatible endpoints) correctly reduce to Unknown via the existing generic custom_endpoint zeroing in resolver.rs:235-245 — this PR doesn't reinvent that check, it just rides the same rail DeepSeek already validated. The new test qwen_native_search_is_exact_to_token_plan_responses_routes (crates/config/src/route/tests.rs:1436-1483) exercises exactly this boundary, including the real Alibaba Coding Plan/Anthropic hosts as adversarial inputs — good test.
• The actual attach point in engine.rs:5888 gates on route.capabilities.server_side_web_search.is_supported() before ever constructing the client, so an unsupported model on the same ApiProvider (e.g. glm-5.2 via ModelStudio) never reaches the wire-format code at all.

Correctness. No bugs found. The ResponsesSearchDialect::ModelStudio arm mirrors xAI's web_search + tool_choice: "required" shape, matches the documented Harness contract cited in the doc comment, and the new mock-server test (modelstudio_adapter_uses_token_plan_responses_contract, line ~767) asserts the actual wire body and endpoint/auth header.

Minor, non-blocking nit — duplicated match arm. In build_responses_search_body (crates/tui/src/client/provider_native_search.rs:225-230), Xai and ModelStudio do the exact same thing:

ResponsesSearchDialect::Xai => {
    body["tool_choice"] = json!("required");
}
ResponsesSearchDialect::ModelStudio => {
    body["tool_choice"] = json!("required");
}

Could be merged into ResponsesSearchDialect::Xai | ResponsesSearchDialect::ModelStudio => { body["tool_choice"] = json!("required"); }. Cosmetic only — not worth blocking on.
Fix this →

Tests. Good coverage: unit test for the payload shape, integration-style mock-server test for the full request/response round trip, and the route-resolution boundary test covering the fail-closed cases (preview model, alternate hosts). No gaps I'd ask for.

Reconciliation quality. Both root and crates/tui/ CHANGELOG.md carry the Qwen and DeepSeek entries cleanly (no merge artifacts), docs/PROVIDERS.md table row is updated to describe the new capability without altering unrelated rows, and offering.rs's existing single-ProviderId-per-plan design (mode/wire handled by config, not separate catalog rows) is left untouched and correctly reused rather than duplicated.

No blocking issues. One cosmetic simplification suggested above (optional).