Opt-in keyless You.com search provider, as a second keyless option next to DuckDuckGo

[brainsparker]

I work at You.com, so treat the recommendation accordingly. There's no CONTRIBUTING file, so I'm asking here before writing any code.

Context. #179 counted 1,341 Exa returned HTTP 429 errors in a GAIA validation campaign, 44% of the 3,039 tool failures, with the DuckDuckGo fallback quietly serving the rest. Since then #199 added same-provider retry and the startup notice, #241 parks a rate-limited provider, #274 persists the cache and cooldown, and #609 (ATO-120) takes keyless Exa out of the chain. So the 429 loop itself is handled.

What's left, as I read search-orchestrator.ts and web-config.ts: with no keys and no SearXNG instance, DuckDuckGo's HTML endpoint is the only provider that can answer. #179 called it "materially weaker for the factual lookups this workload needs", and #237 mentions the challenge page.

Idea. A you provider in src/tools/os/web-search/providers/, opt-in and off by default.

• No key: GET https://api.you.com/v1/agents/search?query=...&count=..., JSON results, no account. The free tier is 100 searches a day. Past that it answers 429 like any quota, so it goes through assertProviderStatus and the existing cooldown. To be clear, this doesn't make rate limits go away. It adds one more keyless provider, with a documented quota, that a user can put in front of DuckDuckGo.
• With YDC_API_KEY: https://ydc-index.io/v1/search with an X-API-Key header, for more volume. A campaign at Keyless Exa search returns HTTP 429 continuously and degrades to a weaker provider silently #179's scale needs a key. The free tier won't cover it.
• Opt-in only: provider: "you", or "you" in fallback. The default config doesn't change. The docs say plainly that queries go to a hosted third-party API.
• Wiring follows the existing contract: the WebSearchProviderName union and parseWebSearchProviderName, a case in provider-registry.ts and isProviderUsable (usable without a key; the key only switches the endpoint), a web.search.you config block (endpoint, apiEndpoint, apiKeyEnv: "YDC_API_KEY"), a you-provider.test.ts like the Brave one, and the README provider list.

For transparency: searchHttp sends a fixed Chrome User-Agent on every search request. On You.com requests only, I'd send User-Agent: youdotcom-integration/atomicbot-ai-atomic-agent instead, so we can see traffic that comes from Atomic Agent. That needs a small change so a provider-supplied User-Agent header replaces the default rather than adding a second one. Nothing changes for the other providers.

Measuring it. If it'd help you decide, I can run a slice of your GAIA validation setup with you as the primary (keyed, so the free quota doesn't skew it) next to your current config, and post the tool-failure breakdown in the same shape as #179. Tell me which split and settings you'd want. I'm not promising numbers up front.

If you'd rather not add another hosted provider right now, say so and I'll close this without fuss.