feat: add optional You.com web search provider

[valueadd-lgtm]

This adds You.com as a third selectable search provider alongside native and Tavily, for the web_search, fetch_page and deep_search tools.

Why this is useful here: You.com exposes a Search API plus a Contents (page-extraction) API, which maps one-to-one onto the two Backend methods — so the provider slots into the existing engine-choice pattern without any new abstraction, and without a new dependency (stdlib net/http only). The You.com API key is a static key from you.com/platform/api-keys.

What changed

• internal/search/youcom.go — YoucomBackend, mirroring TavilyBackend's shape: POST /v1/search for results, POST /v1/contents for page markdown, per-operation timeouts, capped result count, nativePageChars truncation so the fetch_page truncation note stays accurate, and the same error reporting (a 401 is called out as a rejected key).
• internal/search/backend.go — ProviderYoucom = "youcom" in the shared provider constants.
• internal/search/build.go — BuildBackend wires NewFallbackBackend(youcom, nativeChain) when provider is youcom and a key is resolvable. The native chain stays the last link, so a bad key, exhausted quota or network error falls through rather than going dark — same contract as Tavily.
• internal/session/search_store.go — SearchProviderYoucom constant; normalise keeps it (no schema change — the provider column is already a string).
• internal/server/server.go — logSearchProvider logs the youcom selection and warns when YDC_API_KEY is missing, so a silent native fallback is visible.
• Settings UI (web/src/pages/settings/search.tsx, web/src/api/client.ts) — a You.com tab whose row explains that the key comes from YDC_API_KEY in the server environment, with a link to get one. Deliberately no stored credential: the key travels with the deployment, not the database, so no new column, no masking surface, and nothing changes for existing users who never select the tab.
• Docs (docs-site/src/content/docs/search-and-skills.md) — one row in the provider-key env table.

Setup / env

export YDC_API_KEY=***   # https://you.com/platform/api-keys

Then pick the You.com tab in Settings → Web search (or set provider: "youcom"). The change applies live — no restart. Unsetting the key or selecting another provider reverts to native behavior.

Usage example: with the provider selected, web_search results carry provider: youcom; when You.com fails a call, the fallback chain stamps native (youcom fallback) on the rescued answer — the attribution behavior the tools already render for Tavily.

Validation

• go build ./..., go vet ./internal/... — clean.
• go test ./... — full suite passes.
• New unit tests in internal/search/youcom_test.go mirror tavily_test.go (stub HTTP server, no network): request shape (X-API-Key header, path, clamped count), result mapping including the snippets→snippet fallback, empty-URL dropping, page extraction with title derivation and null-markdown failure, 401 → "rejected", blank-key error, and provider stamping.
• New opt-in live check in internal/search/youcom_live_test.go, gated the same way as the native live tests: YDC_API_KEY=*** OGCODE_LIVE_SEARCH_TEST=1 go test ./internal/search/ -run TestLiveYoucom -v. I could not run it end-to-end here (no key on this machine), so the live path is verified by the stub tests plus the gated runner.
• Default behavior is unchanged: the youcom branch only activates on an explicit provider selection, and without YDC_API_KEY that selection resolves to the native chain with a logged warning.

Fallback/error handling: a missing key, rejected key, rate limit or network error all fall through to the native engine chain via the existing NewFallbackBackend; errors are returned with a short capped body snippet and never abort the fallback.

Happy to adjust the shape — e.g. storing the key in the settings surface like Tavily's, if you would rather keep both providers' credentials symmetrical than keep this one env-only.