DeepSeek native search is served by DeepSeek's endpoint, so two checks now
gate the API key, in ready() and again in the key resolver of every search:
- Route: a model request on a route other than deepseek-account,
deepseek-official, and the new `routes` setting is refused with
WEB_PROVIDER_ROUTE_DISABLED, so another provider's conversation does not
bill DeepSeek unless a deployment lists the route.
- Endpoint: the official chat route's own key reference goes only to a
search endpoint on that route's chat origin, read from the active
dsh-llm-deepseek-api-key Loader row with that package's resolver;
otherwise WEB_PROVIDER_ENDPOINT_MISMATCH. A literal key, a separate key
reference, or a search endpoint on the chat origin passes.
The provider passes a resolver's own WebError through unchanged. A real
Loader composition pins the endpoint check. The pi-ai-conversation-updates
scenario gets its own tool sidecar without web_search, and the legacy
deepseek-messages route loses web_search in deepseek-messages-system-prompt.