Support arbitrary/pluggable web search providers

Drafted on behalf of a community request from the Deep Agents Slack: a user running dcode (deepagents-code) at home wants to point web search at their own self-hosted SearXNG instance instead of being required to use Tavily.

Feature description

Today the web_search tool in dcode is hardwired to Tavily. The implementation in libs/code/deepagents_code/tools.py constructs a TavilyClient directly (_get_tavily_client), gates availability on settings.has_tavily / TAVILY_API_KEY, and calls client.search(...) with Tavily-specific arguments. There is no supported way to swap in a different search backend.

This is a problem for:

• Self-hosting / privacy-conscious users who run their own metasearch engine (e.g. SearXNG) and don't want queries leaving their network or going to a third-party SaaS.
• Air-gapped / on-prem deployments where Tavily is unreachable or disallowed.
• Cost / quota — users who already pay for or self-host an alternative shouldn't need a separate Tavily key.

We'd like dcode's web search to support arbitrary / pluggable search providers, with Tavily remaining the default so nothing changes for existing users.

Proposed solution (optional)

A few directions, roughly in order of effort, for maintainers to weigh in on:

1. Provider selection via config/env. Introduce something like SEARCH_PROVIDER (default tavily) plus provider-specific settings (e.g. SEARXNG_BASE_URL). web_search would dispatch to the configured backend while keeping its current input/return shape stable.
2. Built-in SearXNG provider. Ship a SearXNG implementation that hits a configurable instance's /search?format=json endpoint and maps results into the existing {results: [{title, url, content, score}], query} shape that the tool/prompts already expect.
3. Custom-callable hook. Allow users to register their own web_search callable (or a LangChain search tool) so any backend can be plugged in without dcode shipping a built-in for it.

Notes / constraints worth preserving:

• Keep the existing web_search signature and return/error dict shape stable — deepagents-talon imports web_search and fetch_url directly (see the maintainer note in tools.py).
• The existing SSRF guards (_validate_url / pinned-DNS) matter here: pointing search at a user-supplied base URL (LAN SearXNG) needs care so the guard doesn't block legitimate private instances while still protecting the agent-driven fetch_url path. Worth deciding whether self-hosted-search base URLs are explicitly trusted/allowlisted.

Additional context (optional)

• Current Tavily wiring: libs/code/deepagents_code/tools.py (web_search, _get_tavily_client) and libs/code/deepagents_code/config.py (tavily_api_key, has_tavily, TAVILY_API_KEY).
• SearXNG JSON output format: https://docs.searxng.org/dev/search_api.html

Start in libs/code/deepagents_code/tools.py with web_search and _get_tavily_client, then inspect libs/code/deepagents_code/config.py for the existing Tavily settings and availability checks. Review the SearXNG search API format and determine the provider boundary, configuration, and trust handling. Done means an alternative provider can be selected while the existing web_search signature and return/error shape remain stable.