fix: honor required search tools across providers

[dengkai666666]

中文说明

修复内容

• Creative Console 开启 Web/X 搜索时发送 tool_choice: "required"，避免模型自行跳过搜索。
• Console 请求归一化保留 Hosted web_search / x_search 的 required 语义，不再错误降级为 auto。
• 增加搜索能力感知路由：X 搜索排除不支持它的 Web Provider；强制 Web 搜索优先选择支持搜索的 Provider。
• grok-4.5 搜索请求优先选择 Console，因为实测 Build 即使收到 required 仍可能只返回文本、不执行搜索。
• Build 继续隐藏 x_keyword_search、x_semantic_search 等内部实现细节，但合成只读的标准 x_search_call 状态节点，让客户端确认搜索确实执行过。

问题原因

Creative Console 原先只声明搜索工具，没有指定 tool_choice，模型可以选择不调用。Console 归一化又没有把 Hosted Search 视为保留下来的客户端工具，导致 required 被改回 auto。此外，原有 Provider 回退顺序不感知工具能力，X 搜索可能进入 Web，而 grok-4.5 强制搜索也可能先落到当前不会执行搜索的 Build。

Build 响应过滤器会隐藏内部 X 搜索调用。该设计避免泄漏上游实现细节，但也让客户端无法区分“执行过搜索”和“没有搜索”。因此本 PR 只合成通用状态节点，不暴露关键词、用户搜索或线程抓取等内部数据。

路由行为

• X 搜索：排除 Web Provider。
• 强制 Web 搜索：Build → Console → Web。
• grok-4.5 强制 Web/X 搜索：Console → Build → Web。

grok-4.5 的顺序是根据实际兼容性测试增加的处理。长期方案更适合建立 Provider/模型级工具能力元数据，替代模型名特判。

验证

• go test -run TestConversationToolRequirementsRouteByProviderCapability ./internal/application/gateway
• go test -run 'TestFilterBuildPromptCacheResponse(JSON|Stream)' ./internal/infra/provider/cli
• go test -run TestNormalizeRequestAppliesConsoleCompatibilityBoundary ./internal/infra/provider/console
• 使用仓库 Dockerfile 完成前端 TypeScript 与 Vite 生产构建。

实测同等 required 请求下，Build 的 grok-4.5 没有产生搜索调用；Console 可以完成原生 Web/X 搜索。Web Provider 不能执行 X Search，因此路由层会将其排除。

---

Summary

• send tool_choice: "required" when Creative Console search switches are enabled
• preserve required hosted web_search and x_search tools in Console request normalization
• make conversation routing aware of search capabilities and keep X search away from Web routes
• prefer Console for grok-4.5 search requests because Build currently ignores required hosted search
• expose a synthetic completed x_search_call after filtering Build internal search implementation details

Problem

Creative Console previously declared search tools without a tool_choice, so the upstream model could skip them. Console normalization also treated hosted search tools as if no client tool had survived and downgraded required to auto. In addition, provider fallback was not capability-aware: Web cannot execute X search, and a required grok-4.5 search could land on Build even though that route currently returns plain text without a search call.

The Build response filter intentionally hides internal calls such as x_keyword_search and x_semantic_search, but that also made a successful X search indistinguishable from no search. This change retains the filtering and emits only a provider-neutral, read-only x_search_call status item.

Routing behavior

• X search excludes Web routes.
• Required Web search prefers Build, then Console, then Web.
• grok-4.5 with required Web or X search prefers Console, then Build, then Web.

The grok-4.5 ordering is an observed compatibility workaround. A longer-term model/provider capability registry would be preferable to a model-name special case.

Verification

• go test -run TestConversationToolRequirementsRouteByProviderCapability ./internal/application/gateway
• go test -run 'TestFilterBuildPromptCacheResponse(JSON|Stream)' ./internal/infra/provider/cli
• go test -run TestNormalizeRequestAppliesConsoleCompatibilityBoundary ./internal/infra/provider/console
• frontend TypeScript and Vite production build via the repository Dockerfile

Upstream validation with equivalent required requests showed Build grok-4.5 returning no search calls, while Console completed native Web and X searches. Web remains excluded from X search because it cannot execute that hosted tool.