feat(app): wait_for_status + read_terminal on the live bridge (F-mcp-terminal-sync, #195)

ROADMAP.md

@@ -374,8 +374,23 @@ geometry) with drag-resize split out to #55 (blocked-by #54; feature-torture
     click-to-focus (`FocusPane`) only reaches the active one and a silent no-op
     there would let a close destroy the wrong terminal. Depends on #193; with #212
     (perception) this closes the act→observe loop
-  - [ ] `F-mcp-terminal-sync` (#195) — `wait_for_status` (OSC) + `read_terminal`;
-    depends on #193
+  - [x] `F-mcp-terminal-sync` (#195) — **the wait rung**, closing
+    act→**wait**→observe. `wait_for_status` blocks until a session's OSC-derived
+    activity reaches one of the asked-for statuses (default idle-or-attention),
+    and `read_terminal` returns one pane's visible text — the deep read the
+    light `snapshot` leaves out. The wait is the first bridge request whose
+    reply lands in a *later* `update`: the shell parks the reply port in a
+    waiter list and settles it from the status change, so nothing is polled and
+    no transition is raced (the feature-torture report cut `wait_for_text` for
+    exactly that). Three rules earn their tests: a session already on the target
+    answers at once (never wait for a transition already past); an exit settles
+    every waiter whatever was asked for (a crash emits no status change, and a
+    dead session will not reach the target); a caller that gave up is swept off
+    the list. Timing out is not an error — the tool reports
+    `{ status, timed_out: true }` with the session's current status, so an agent
+    can choose between waiting again and giving up. Bounds are the caller's:
+    `timeout_ms` (default 30 s) capped at 5 min (Q7). Depends on #193; unblocks
+    #196
   - [ ] `F-mcp-agent-loop` (#196) — `type_into_terminal` + prompt→wait→read,
     opt-in; depends on #195; product-scope question open (may be cut)
   - [ ] `F-mcp-screenshot` (#215) — expose the window PNG as an MCP tool (async