feat(runtime): restore DeepSeek native WebSearch on Open Responses #3689

Problem

#2972 deliberately disabled first-party DeepSeek model-native WebSearch when DeepSeek moved to @ai-sdk/open-responses, because that adapter dropped provider-defined tools and did not decode hosted tool results. Tavily and the Anthropic-compatible DeepSeek path remained alternatives.

The shared adapter work in #3685 now lowers tools: [{ type: "web_search" }] and preserves all observed Responses actions (search, open_page, and find_in_page). A real first-party probe on 2026-08-24 used deepseek-v4-flash through https://api.deepseek.com/responses: six provider-executed WebSearch calls completed with a grounded answer and a normal stop outcome.

The transport is therefore ready, but resolveHostedWebSearchCapability(deepseek, ...) still returns implemented:false, so normal Maka composition never advertises the tool.

Desired outcome

Restore native WebSearch for first-party DeepSeek V4 Responses models after #3685 lands.

• Enable the implemented capability for deepseek-v4-flash and deepseek-v4-pro only on their effective Responses wire.
• Preserve explicit openai-chat model overrides, privacy-mode removal, scoped child tool ceilings, and explicit no-fallback behavior.
• Keep provider-executed search history on the existing grounded-text fallback until Open Responses can round-trip hosted call/result pairs safely.
• Add capability and production-routing regressions plus a normal routed live smoke.

Alternatives or workarounds

Users can select Tavily with a separate credential, or configure the DeepSeek Anthropic-compatible endpoint and use web_search_20250305. Neither restores the first-party Responses capability that was intentionally disabled in #2972.

Related: #2152, #2927, #2972, #3685.