Two commits since v0.29.0, both from the same source: Stoat wired `stoat runner` to 0.29.0 and
drove a real resident runner from it, and the five issues that came back are what a parent and
a monitor actually need from one. All additive — the wire gained a trailing optional field, the
API gained types and members, and nothing a 0.29.0 consumer wrote changed meaning.

What Stoat is waiting on:

- #397 BOBCAT_RUNNER_ID is the runner's id when set, so the same checkout is the same runner
  across every rebuild; and a restart exits 75 (EX_TEMPFAIL) while an orderly stop still exits
  0, so a parent can tell "relaunch me" from "I'm done" without asking the monitor.
- #400 RunnerAcknowledgement carries a machine-readable `refusal` — busy | unknown-spec |
  unsupported-mode | empty — beside the human reason. Busy means "send it again" and the other
  three do not, and Stoat was telling them apart by matching the sentence.
- #401 a run carrying a Command reports no Session: a resident runner holds its launching
  agent's session for life and was claiming every button press a person made.
- #398 resident mode on BobcatRunner.Run, not only the MTP host, so a suite written against the
  command family — Stoat's own specs included — can be driven from a console's run buttons.
  ResidentMode moved to core for it.
- #399 OutOfProcessResidentSuite plus `bobcat resident <host>`: a cold resident runner for a
  projected suite, whose process belongs to its test framework.

One thing to know before upgrading the tool: the `bobcat` tool's ASSEMBLY is now Bobcat.Cli,
because it references core and `bobcat.dll` beside `Bobcat.dll` is one file on a
case-insensitive filesystem. The command a person types is unchanged, and so is the package id.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_019U1ut5qK9Y9ofxU7dKw7TC