tool-select inert on K3: `dynamically_loaded_tools` capability not declared in the served model catalog

Summary

The experimental tool-select flag (progressive tool disclosure) cannot take effect on K3: the served model catalog never declares the select_tools/dynamically_loaded_tools capability, so MCP tool schemas are still sent in every request even with the flag enabled.

Evidence (2026-08-19, kimi-code 0.36.1)

• [experimental] tool-select = true is set in ~/.kimi-code/config.toml (via the TUI experimental panel).
• Fresh session wire: zero select_tools/dynamically_loaded_tools references; all 10 configured MCP servers' full tool schemas are discovered and loaded upfront (mcp.tools_discovered carries full inputSchema per server).
• GET https://api.kimi.com/coding/v1/models (subscription endpoint): the k3 entry declares reasoning/image/video/think-effort capabilities only — no dynamic-tool-loading capability.
• Changelog gates the feature on exactly this: 'only active on models that declare the capability' (0.23.x), capability renamed select_tools → dynamically_loaded_tools in 0.24.1.

Ask

Declare the dynamically_loaded_tools capability for k3 / k3-256k (and ideally kimi-for-coding*) so the tool-select flag can actually defer MCP tool schemas — currently the flag is set-but-inert, and users with larger MCP rosters pay the full schema cost in every request (and lose it again at each compaction, since 0.23.x already discards loaded schemas there).

Start at the GET https://api.kimi.com/coding/v1/models entry and inspect how the k3 and k3-256k catalog records expose capabilities. Trace the tool-select capability gate, then verify that the catalog declares dynamically_loaded_tools and that enabled tool-select no longer loads every MCP schema upfront.