TRI CLAW: port its ~170 tool handlers to .t27 and mount the 26 t27-mcp tools at its /mcp #10489

Goal

The owner (2026-10-18): TRI CLAW's tools must move to .t27, and the t27-mcp tools must move into it. Today TRI CLAW (gHashTag/999-multibots-telegraf, service vibee-render, POST /mcp) serves about 170 tools in hand-written TS, and only t27_specs of the t27 tools is mounted. The local stdio server gHashTag/t27-mcp serves 26 tools (t27_check, t27_spec, t27_grep, t27_examples, t27f_outline, t27_dashboard, ...), whose logic is already t27 compiled to wasm.

Plan

1. Mount: the 26 t27-mcp tools in TRI CLAW's /mcp through admit() of specs/t27mcp/service.t27 (One MCP service: mount the t27 tools into TRI CLAW's /mcp #10483 landed the spec; the mount itself is not live). The t27 wasm modules are reused, not copied (DRY).
2. Retire the 7 tg_* forwarders in t27-mcp once the mount answers.
3. Port: TRI CLAW's tool logic to .t27 specs, family by family (crm_*, tg_*, mail_*, plan_*, hive_*, browser_* ...), each family a sub-issue, leaving only thin I/O glue in TS (only-t27 cap: 40 lines per file, 80 per PR).
4. One MCP entry for Claude Code: the TRI CLAW endpoint; the local t27 server stays as the keyless fallback.

Scenarios

• Given an agent with only the TRI CLAW endpoint configured, When it lists tools, Then t27_check and the other mounted t27 tools are there and answer.
• Given a ported tool family, When its spec tests run, Then they pass with 0 vacuous and the TS handler shrinks to glue.

Refs #10483