Add Kiro CLI as a third host #42

I'd like to add Kiro CLI as a third host, next to Claude Code and Codex. Before I write a PR, I want to check that you'd take it and agree on the shape.

Why

I run t3-pstack from Kiro CLI threads in T3 today (T3 drives kiro-cli over ACP). It works, but only through local glue: a script that links the plugin's skills into the Kiro home, and a steering file that stands in for the session-start hook. Every Kiro user would have to rebuild that by hand, and it drifts with each release.

The skill text and the t3-code MCP dispatch already work on any host. What's missing is packaging and a few host-specific lines.

What Kiro already has

Kiro docs: hooks, hook types, skills, powers, ACP.

What would change

• Installer and doctor. A tools/install/kiro.mjs that finds the Kiro homes (~/.kiro, plus the home of any Kiro instance in T3's settings), installs the skills, and writes a SessionStart hook file. It gets --kiro-home <dir> like the other two, and doctor gets the same checks.
• Session-start hook. A kiro case in hooks/session-start.sh. A global Kiro hook isn't tied to a plugin root, so the hook file the installer writes would pass the installed path. The hook template would get pinned in tools/frozen-hooks.json like the other two.
• Substitutions. 14 of the 171 rules name a host. About five need a Kiro clause: the install line, skill naming, the plugin-directory lookup, and the user skills directory (.kiro/skills, not the .agents/skills fallback). The question-tool rule's plain-text fallback already fits, and reflect's transcript finder can stay Claude Code and Codex only at first. No new forks.
• Tests next to the Claude Code and Codex ones. The install e2e test would need kiro-cli on the runner.

Open questions

1. Do you want a third host in the port, given what it adds to each sync? The rule changes add clauses to existing host lines; none of them are forks.
2. Plain skills or a Power? Plain skills in ~/.kiro/skills/ are what I run today. A Power is one install unit, but Kiro loads a Power's context when keywords match, which may not suit poteto-mode entering on its own. Plain skills also have no namespace, so /how and /why could collide with a user's own skills.
3. On stock T3, Kiro would join as a local-command ACP agent (kiro-cli acp). Before opening a PR I'd confirm two things on that path: that the t3-code MCP tools reach the thread, and that the SessionStart hook fires there in place of my steering file.

If the shape looks right, I'll send the PR.