feat: add opt-in tool discovery for large MCP catalogs

[spawnax]

Agent Host sessions with 135 enabled tools fail the extension's 128-function guard before the model can answer. Add opt-in provider-side discovery so large host catalogs stay available while each API request carries a bounded set of schemas.

Closes #288. Related to #286: the existing guard remains when discovery is disabled; this PR does not establish or change the server-side maximum.

Behavior

• experimental.toolDiscovery.enabled defaults to false and takes precedence over tool-list stabilization.
• experimental.toolDiscovery.maxTools bounds schemas per request, including the synthetic search function: default 64, range 8–128.
• Oversized catalogs begin with core/recent tools and deepseek_search_tools. Lexical search and paginated browsing expose original schemas on subsequent requests. Evicted schemas remain discoverable. Small catalogs pass through unchanged.

The catalog contains only tools supplied in the current host request. Real calls, including activate_* calls, return unchanged to Copilot for validation, execution and approvals. A host-provided tool may be called directly from conversation context even when its schema is currently deferred or evicted; schema selection is not a separate authorization boundary.

Calls absent from the host catalog never reach the host. Instead, the model receives explicit non-execution feedback and can retry with an available tool. If a response mixes unavailable and valid real calls, none of those real calls are emitted before correction; their feedback explicitly says they were not executed. Search and recovery share a maximum of four internal continuations (five API requests total). Cancellation, reasoning and tool-call correlation are preserved.

English/Chinese settings documentation and CI coverage are included. No dependencies are added. MCP server lifecycle remains with Agent Host.

Validation

• TypeScript compilation, lint with zero warnings/errors, formatting and git diff --check passed.
• All 22 tests passed: 135/500-tool catalogs, pagination/eviction, original schemas and arguments, Unicode search, direct deferred calls, removed tools, mixed-call recovery, cancellation, network errors, bounded retries, required mode, catalog isolation and provider opt-in/out.
• Local HTTP/SSE tests exercise the actual client in three flows: search then real call (two requests), direct deferred call (one request), unavailable-call recovery then search and real call (three requests). The tests make no paid API calls and execute no real tools.
• VSIX built and ZIP integrity verified. Compared with the installed experimental build, only out/provider/tools/discovery.js changes at runtime. The initial discovery build was confirmed working by the affected user; this follow-up recovery fix still requires confirmation in their live chat after reloading VS Code.

Experimental limitations

Internal continuations add billable requests and latency. Responses are buffered until each round finishes. Search is lexical, the catalog is rebuilt per provider invocation, and internal search/recovery history is not persisted in the host chat. Existing request dumps describe the initial request; per-round diagnostics and multi-request context/usage presentation still need further validation.

• I reviewed and can explain every change
• I reviewed user-facing text changes in English and Chinese
• No API keys, authorization headers, private prompts, private code or private logs are included