Runner resilience under agent-abuse command patterns

[thymikee]

Found by the first headless-Haiku benchmark run (#1101): a small-model agent hammering the CLI in tight act/observe loops (38 turns in ~6.7 min, including malformed and rapid-fire commands) wedged the iOS runner hard enough that snapshot requests kept timing out even across a subsequent open --relaunch. The daemon correctly survived (preserve-on-snapshot-timeout policy from #1075) but the runner never self-recovered — it needed a process kill.

This is a new workload class: adversarial-by-incompetence. Strong models pace themselves; small models retry fast, interleave commands mid-flight, and abandon sessions mid-request. Best-in-class agent reliability means the runner recovers from this without human intervention.

Investigation starters:

• Reproduce with a scripted rapid-fire pattern (the benchmark harness in press/click/fill --settle: settled observation in the interaction response #1101 can be adapted); capture the runner state when wedged (last diag phases, whether the AX-unavailable invalidation fired and got stuck re-acquiring).
• The --relaunch path should arguably detect a runner whose last N commands all timed out and recycle it proactively (kill + fresh start) instead of reusing the session — the keep-hot machinery has the health signals (readiness preflight, invalidate/restart-and-replay) but apparently a state exists where none of them trigger recycling.
• Consider a daemon-side circuit breaker: M consecutive runner command timeouts → forced runner restart on next command, with a diagnostic explaining why.

[thymikee]

Update: this is worse than agent-abuse — it reproduces deterministically with slow, paced, plain commands (no --settle, no rapid fire). Repro tonight on the Bluesky dev build (iPhone 17 Pro sim):

1. Search → fill "alpenglow" → press the first account result (profile screen opens)
2. snapshot -i on the fully-rendered profile: 9.3s for 133 nodes (normal screens: 400–700ms)
3. next press "label=Notifications": 92s wall → COMMAND_FAILED "Daemon request timed out"
4. afterwards every command fails SESSION_NOT_FOUND until a full re-open

Per-request phase log of the 92s press: the daemon performed two complete runner restarts inside the single request — ios_runner_session_invalidated → ios_runner_simulator_app_terminate_failed ×2 → full ios_runner_session_startup (xcodebuild boot, ~25s) → ~16 readiness retries → ios_runner_command_send → dies at snapshot_capture → invalidated again → second full startup → dies at snapshot_capture again → request_failed. A fresh runner also can't capture this screen, so the hang is in the capture itself (the depth ladder from #758 is merged; this looks content-dependent — the same flow had ~400ms observes two days ago).

Three-layer fix now in progress (branch fix/ios-capture-stall-recovery): (a) time-bound the capture end-to-end and return a sparse/degraded verdict instead of hanging; (b) at most one runner recycle per request, then fail fast with a hint; (c) never drop the app session on a capture/runner failure — the app is still running fine.

Impact framing: this single wedge is what killed every headless-agent benchmark run so far (Haiku had the task 60% done in 5 clean turns before hitting it, then spent 35 turns flailing on SESSION_NOT_FOUND).