fix(miot-chat): handle new harness event types in transcript projector

Task 2's event-type parity fix widened HarnessEvent["type"] with six
literals (approval.auto, decision.requested, decision.resolved,
steering.mode_denied, steering.injected, run.interrupted). applyHarnessEvent
is an exhaustive switch with no default, so the unhandled cases let it fall
through -> TS2366 'Function lacks ending return statement' in check-types.

Add explicit cases: run.interrupted joins the terminal run.completed/
run.failed group; the run-control/steering events are explicit no-ops
(the legacy approval.requested row still renders; the decision/steering
TUI migration is out of scope). Kept default-less so future event types
keep tripping the type-checker until handled.

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

Author: claude

turbo-repo/packages/miot-chat/src/tui/transcript/project.ts

@@ -32,11 +32,29 @@ export function applyHarnessEvent(
 
     case "run.completed":
     case "run.failed":
+    case "run.interrupted":
       // The session reducer's END_TURN orchestrates the final transition;
       // mid-stream we leave the transcript alone so callers don't have to
-      // race the projector against END_TURN.
+      // race the projector against END_TURN. run.interrupted (Plan C) is a
+      // graceful stop and terminates the run like the other two.
       return slice;
 
+    case "approval.auto":
+    case "decision.requested":
+    case "decision.resolved":
+    case "steering.mode_denied":
+    case "steering.injected":
+      // Plan A/B/C run-control + steering events. The transcript still
+      // renders the legacy approval.requested row (dual-emitted alongside
+      // decision.requested for tool approvals), and the decision/steering
+      // TUI migration is out of scope here — so these are intentionally not
+      // projected. They are handled explicitly (rather than via a default)
+      // to keep this switch exhaustive, so any future event type keeps
+      // tripping the type-checker until it is handled. Surfacing them in the
+      // TUI is a follow-up.
+      return slice;
+
+
     case "answer.completed":
       return upsertAssistantItem(slice, event, runId, ctx);