harness: wire native tool categoryHint/ToolCategory into deferred tool-search groups (item 9 of #4267) #4353

Part of #4267 (harness friction umbrella, item 9).

Problem

Deferred tool discovery (tool_search, provider alias maka_tool_search) reduces the always-visible catalog, but native tools currently collapse into a single synthetic other group, so the model gets little signal about which capability families exist. A poorly phrased search then misses a native tool and falls back to Shell/scraping.

Meanwhile a real taxonomy already exists — it's just not surfaced to discovery:

• tool-availability.ts pushes every ungrouped tool into { id: 'other', toolNames: ungrouped }; groups are populated only from client-capability (MCP) snapshots (interactive-run-composer.ts sets groups from clientCapabilities?.groups), so native deferred tools (deep-research, subagents, computer-use, history, …) have no family label.
• permission.ts already defines ToolCategory and every tool carries a categoryHint (e.g. subagent, web_read, computer_use, client_capability) — used today only for permission classification.

Proposed work

Wire the existing categoryHint / ToolCategory values into tool_search groups at composition time, so the model can see a compact capability-family map (filesystem, shell, web, browser, agent orchestration, scheduled work, …) without loading every tool schema.

Open questions to settle first

• Do permission-category and discovery-category semantics fully match, or do they need a separate discovery tag set?
• Can one tool need multiple discovery tags?
• Keep other as the fallback bucket.
• Grouping must never change permission behavior.

Acceptance

• Native deferred tools are grouped by capability family in the searchable inventory, not dumped into other.
• No tool schema is eagerly loaded to produce the grouping.
• A test asserts representative native tools land in the expected family group and that permission classification is unchanged.

Note: the Paseo skill naming/tool mismatch mentioned under item 9 originates from an external, user-global skill, not a repo file, and is tracked separately (validate-declared-tools should warn, not hard-fail).