[alexandre-vl]

Windows CI's harness-app-tests fails in about one run in five, in cursor_shim, with bounded frame: Elapsed(()) (crates/harness/tests/cursor_shim.rs:192 on main). Every frame these tests read has 5 s to arrive (:190), and a shim's first frame also waits for node to start, which on the Windows runners has taken longer than that by itself. A shim's first frame now gets 30 s; every frame after it keeps 5 s. Test-only.

What changes

• frame() waits 30 s for a shim's first frame and 5 s for each later one (crates/harness/tests/cursor_shim.rs:196-207).
• Frames wraps a shim's stdout lines and remembers whether its first frame has come (:171-195). Every place that starts a shim returns one (spawn, start_frame, and the engine-death test's parent process). Tests that time a frame themselves still call next_line() on it.

Where it fails

• main's Windows push runs: harness-app-tests failed in 6 of the 30 from October 22 to 25 (a9e6c48, ea3dcc8, 684becf, 0e1b891, fd7d268, 1ec71a3), each time in cursor_shim. Providers: a switch to turn native subagents off #1046 hit it twice in a row.
• In those eight logs, the first failures land 5.04 to 5.14 s after cursor_shim starts. They always include the four tests that sort first, which start their shims together: a_model_switch_names_its_model_from_its_own_send_on, a_reply_that_is_only_a_transport_dump_fails_the_turn, a_send_with_no_update_at_all_is_abandoned_at_the_bound and a_settled_reply_that_never_streamed_is_still_shown. The tests after them pass, or fail the same way 5 s later while node is still slow to start.
• A slow node start on a loaded runner is also why scripts/ci/nextest.toml:18-24 retries an opencode test on Linux.

Testing

• macOS 27.0, rustc 1.99.1, Node 24.18.0: cargo test --locked -p zeron-harness --features native-fixture --test cursor_shim gives 31 passed, on main (255c540) and on this branch.
• The same test with a node that takes 6 s to start (a script first in PATH that sleeps 6 s, then runs Node):
  • main: 3 passed, 28 failed, all 28 at cursor_shim.rs:192:10 with bounded frame: Elapsed(()). The 3 that pass are the one-shot run_shim tests, which wait up to 10 s for the whole run (cursor_shim.rs:17-28).
  • This branch: 31 passed, in 1254 s. stress_100_interrupted_sessions_recover_without_losing_history_or_replaying alone starts 201 shims, one after another.
• Not run: Windows. This PR's CI run is the check there.

Known limits

• A shim that hangs before its first frame now fails its test after 30 s instead of 5 s.
• A first frame that a test expects soon after acting gets the same 30 s. In a_stop_during_startup_retries_is_not_lost (cursor_shim.rs:981) it is the cancelled turn. The test still catches a lost stop: it checks that the catalog was fetched once and that no prompt was sent (cursor_shim.rs:1006-1007).
• run_shim's 10 s bound is unchanged: none of its three tests failed in those eight logs.

---

^{Need help on this PR? Tag @codesmith-bot with what you need.}

[zeronsh]

Audited (test-only change to crates/harness/tests/cursor_shim.rs; no deps, CI, or network changes) and reviewed. A shim's first frame is its ready event, so giving it 30 s and keeping later frames at 5 s waits on readiness with a bounded timeout rather than sleeping. I replaced the Deref/DerefMut passthrough with a small Frames::next_line. Locally on current main, cargo test -p zeron-harness --test cursor_shim passed 9 of 9 runs and clippy is clean for the file. The ui-tests and engine-tests failures in run 40384413323 are unrelated Windows tests in crates/ui and crates/engine.