fix(loop): detect a silent harness and hand the task to another one

[sreekar2403]

What / Why

A harness that goes quiet used to cost a whole task. The observed run: the router sent work to pi with a local ollama model that never loaded. pi printed its session header, agent_start, turn_start — and then nothing. The run deadline is five minutes and only catches a CLI that is slow, so the task sat there, and when it finally gave up the loop's only move was to ask the same stuck binary again with a slightly reworded prompt. Ten iterations, no work done, no reason surfaced.

This adds a silence watchdog and a fallback to a different provider:

• runHarness now watches for a gap with no byte on either stream. Every one of these CLIs prints something every few seconds while it is genuinely working, so a long gap is a reliable signal that nobody is coming. The run is stopped and reported as silent — a condition of its own, distinct from timedOut (ran slowly, deadline caught it) and from a plain non-zero exit (ran, failed, said why).
• LoopEngine treats silence as "this harness never attempted the task" rather than a failed attempt: it drops the harness for the rest of the run, drops the harness and model pins, and routes again over what is left. The prompt is passed through untouched — the next CLI gets the original request, not one with a note about somebody else's failure stapled to it. When every harness has gone silent it stops and says so instead of burning the remaining iterations.

It also fixes a related silent failure. Several CLIs report a failure as an error event on stdout and exit non-zero with stderr empty — opencode answering a dead model with "Unexpected server error" is the case that prompted it. That message reached the activity trail and nowhere else: the loop's retry check reads stderr and the chat window reads output, and both were blank. The run failed, said exactly why, and nobody was listening. The error text is now lifted out of the event stream into both.

Two knobs in Settings → Execution: loop.idleTimeoutMs (default 120s, 0 disables) and loop.harnessFallback (default on).

Review fixes in 536308f:

• A clean exit is never silent. silent was computed from output alone and checked before success, so a harness that exited 0 while saying almost nothing had its succeeded run discarded and the task handed to a second CLI to redo.
• The exit fallback now arms only for runs we killed. It exists for the Windows case where a killed shim leaves a grandchild holding the pipe and close never fires (the run would hang forever holding a ConcurrencyGate slot); armed for every run it raced a healthy child still draining its stream.
• loop.idleTimeoutMs and loop.harnessFallback are validated on PUT /api/settings like every other loop key.

How tested

• pnpm lint
• pnpm exec tsc --noEmit
• pnpm exec vitest run — 406 server tests pass
• hive doctor

New coverage, against real subprocesses rather than mocks — the behaviour under test is what happens when pipes go quiet, which a mock cannot reproduce:

• runner.test.ts — a child that prints a header then nothing is stopped and reported silent; a slow-but-talking child is left alone; a quiet successful run is not called silent; a cancelled run is not called silent; idleTimeout: 0 disables the check; an error-only run reaches stderr and output.
• loopEngine.test.ts — the task moves to another harness rather than back to the silent one; the dead harness's model pin does not travel with it; the loop stops once every harness is silent (2 attempts, not maxIterations); the prompt is unchanged across the switch; harnessFallback: false is respected.

Breaking changes

None. Both config fields are new with defaults, and deepMerge over createDefaultConfig() backfills them for configs written before they existed.

Closes

N/A — found in a real run rather than filed.