monitor-test-run

## Overview Given a `testRunId`, watch the run and narrate it. The skill: 1. Reads `live_remediation_enabled` **once** via `getOrgSettings`, so it can explain deterministically what happens when an execution is blocked. 2. Runs the bundled `scripts/poll-test-run.js` in the background — it watches the run and emits a line **only when an execution's state changes** (the model never hand-polls). 3. Reacts to those emitted lines: surfaces a blocker (with the live-remediation URL) when one appears, stays silent in between. 4. On the poller's `DONE`, does a post-mortem so a blocker is never mistaken for a pass. The skill is conversational: its "output" is the messages it posts to the user (events + final summary), not a value returned to a caller. It changes nothing server-side except, optionally, `terminateTestRun` if the user asks to stop the underlying run. > **Tool naming.** This doc refers to Kobiton MCP tools by their bare names (`getOrgSettings`, > `terminateTestRun`). The registered name depends on how the host loaded the MCP server (Claude Code as > a plugin exposes `mcp__plugin_automate_kobiton__getOrgSettings`; a repo-local `.mcp.json` exposes > `mcp__kobiton__getOrgSettings`; other hosts differ). Use the bare name and let the host resolve the > prefix. (Run state is read by the bundled poller over REST, not via the MCP `getTestRun` tool — a > background process can't call MCP tools.) ## Prerequisites - **An authenticated Kobiton MCP connection.** All thre...