Python: You.com web-search TextSearch connector (zero-config keyless tier) — in-tree or out-of-tree?

Proposal: You.com web-search TextSearch connector (Python)

Per CONTRIBUTING.md ("file an issue and start a discussion before spending time on a PR"), asking before opening any PR.

What: a YouSearch connector implementing semantic_kernel.data.text_search.TextSearch, mirroring the in-tree connectors/brave.py anatomy (KernelBaseSettings config, httpx, TextSearchResult mapping, filter lambdas, unit tests following test_brave_search.py, sample following brave_text_search_as_plugin.py).

Why it's different from existing search connectors: it works with zero configuration. You.com has a keyless free tier (IP-rate-limited, 100 searches/day), and the connector defaults to it when no YDC_API_KEY is set — so SK users can evaluate a web-search plugin without provisioning keys through Key Vault or similar. With a key it uses the keyed Search API.

Working implementation: https://github.com/brainsparker/youcom-semantic-kernel (published out-of-tree per the CONTRIBUTING.md guidance on hosting plugins in separate repositories; 21 tests incl. live keyless/keyed, ruff + mypy clean). I work at You.com and we'd maintain the connector either way.

The ask: would you accept this in-tree as semantic_kernel/connectors/you.py (single file + tests + sample, Brave-sized footprint)? If SK is feature-frozen in favor of Microsoft Agent Framework (as with #13295), we'll keep it out-of-tree — in that case, is there a recommended way to make community TextSearch connectors discoverable to SK users, and is agent-framework the right place to propose a You.com web-search tool?

Read CONTRIBUTING.md and the referenced issue #13295 to understand the project's direction for new connectors. Compare the proposed YouSearch connector with connectors/brave.py, test_brave_search.py, and brave_text_search_as_plugin.py; done means a maintainer decision on in-tree placement or community discovery guidance.