fix(codex-bridge): make the turn watchdog an idle timeout, not a fixed ceiling

[Masashi-Ono0611]

Summary

startTurnWatchdog() arms a single fixed-duration timer from turn start
(--turn-timeout, default 60s) and never touches it again until the turn
ends. A turn that is genuinely still working — reasoning, running tools,
composing a multi-step reply — for longer than that gets cut off by this
timer before it ever reaches its own send.sh call. onTurnEnded() then
runs exactly as it does on a real completion, so the bridge silently re-arms
as if the turn had ended with nothing to report; whatever it was about to
send never goes out, and the requesting peer sees only silence.

This turns the watchdog into a true idle timeout: any thread-scoped
app-server activity for the active turn re-arms it, so a turn is only ever
cut off after turnTimeout seconds of true silence, regardless of how long
it has been running in total. This preserves the watchdog's actual purpose
(rescue a turn that will never send turn/completed — the app-server does
not reliably send it, see #41) — a turn that is visibly still working is not
that case.

Implementation

• AppServerClient/WebSocketAppServerClient (both transports) gain an
  onThreadActivity callback, invoked from handleLine() for every
  thread-scoped notification/request — including the many the bridge has no
  specific handler for (reasoning deltas, tool-call/command-output progress,
  etc.), which the existing handlers Map otherwise drops silently before
  dispatch. This is deliberately generic rather than enumerating specific
  event names: the exact set of "the turn is doing something" notifications
  isn't fully known/stable to this bridge, and a generic hook can't miss one.
• CodexBridge wires onThreadActivity to re-arm startTurnWatchdog() for
  its own active thread/turn.
• onAgentMessageDelta's own re-arm (an earlier, narrower iteration of this
  fix) is now redundant and removed — the generic hook already covers it.

Observed in production

A Codex bridge turn spent well over 60s diagnosing a GitHub auth/DNS
failure (correctly identifying an invalid gh CLI token and a
network-restricted sandbox, and proposing next steps) but the watchdog fired
before it reached send.sh, so the diagnosis was silently lost and the
requesting peer received nothing.

Test plan

• tests/test_codex_bridge.bats:

  • "an actively-streaming turn is not cut off by the idle watchdog past
    turn-timeout" (agent-message deltas keep it alive well past the nominal
    timeout, then a real turn/completed ends it — never the watchdog).
  • "non-message turn activity (reasoning/tool-call progress) also re-arms
    the idle watchdog" (same shape, but only item/reasoning/textDelta and
    item/commandExecution/outputDelta — never agentMessage/delta — to
    prove the fix isn't scoped to one specific notification type).

• bats tests/test_codex_bridge.bats tests/test_codex_bridge_launcher.bats —
  47/47 passing (30 pre-existing + 2 new here, plus the launcher suite),
  including the existing watchdog regression tests (Explore a monitor-equivalent delivery mode for Codex #41, Codex bridge: thread stuck in waitingOnApproval deadlocks delivery forever (bridge can't answer approval requests; launcher never replaces the hung bridge) #299) unmodified
  and still green.

• Reviewed via /review:self-multi-model (Codex + Fugu) before submission:
  Codex's first pass correctly flagged that an earlier iteration of this fix
  only re-armed on agentMessage/delta and missed the multi-step
  reasoning/tool-call case above — addressed by the generic
  onThreadActivity hook in the commit history here, with a dedicated
  regression test.

• CI green