Harness waits fail under load on a fixed 10s "the agent never started" deadline #200

This was generated by AI during triage.

Agent Brief

Category: bug
Summary: The test harness's fixed 10s "the agent never started" deadline fails tests on a busy machine

Current behavior:
The harness helper that starts a Run, waits for the fake agent to start, and then sends a signal gives the agent a fixed 10 seconds to appear. On a loaded machine (4 cores, load 21–24, on 2026-09-30), ctrl_c_after_the_merge_finishes_the_post_merge_steps_and_exits_as_merged failed twice in a row with "the agent never started". It passed when its test binary ran on its own. Before the agent starts, the Run makes several git calls and Python fake gh calls, and under load each can take about half a second. An agent session running the full suite during a busy Run sees a failure unrelated to its change and may spend a Repair chasing it.

Desired behavior:
Tests that wait for a Run to reach a point (the agent starting, or a prompt appearing on the pseudo-terminal) don't fail just because the machine is slow. They still fail fast when the Run really never reaches that point, e.g. it exits before starting the agent.

Key interfaces:

• The harness helpers that start a Run and wait for the fake agent's "started" marker before sending a signal, and any sibling wait with the same fixed 10s deadline (e.g. the keystroke/prompt wait)
• Suggested contract: stop waiting as soon as the Run's process exits (fail with its stderr), and otherwise allow a much longer upper bound (e.g. 120s) that only a truly hung Run reaches

Acceptance criteria:

• A wait fails as soon as the Run exits without reaching the awaited point, and the failure message includes the Run's stderr
• A wait no longer fails on a slow but progressing Run within its (much longer) bound
• ctrl_c_after_the_merge_finishes_the_post_merge_steps_and_exits_as_merged passes while the machine is under heavy parallel load, e.g. with cargo test running in two other checkouts
• The full suite passes and takes no longer on an idle machine

Out of scope:

• Making the suite faster in general (Make the test suite faster #174)
• Changing the Run's own timeouts or behavior