buzz-acp: no progress-based liveness check — stuck agents run silently until 2-hour max_turn ceiling

[astromara]

Describe the bug

buzz-acp allows agent turns to run for up to 2 hours (max_turn=7200s) with no progress-based liveness check. The harness cannot distinguish a stuck agent from one legitimately working, so silent hangs are only detected when the hard ceiling is reached or the user explicitly cancels.

Steps to reproduce

1. Trigger an agent turn that hangs mid-execution (e.g. a blocking tool call, unresponsive API, or infinite reasoning loop)
2. Observe that the harness logs extending in-flight deadline by 7200s each time the agent renews
3. Wait — the turn continues silently until the 2-hour ceiling or manual cancel
4. On cancel, if the agent does not drain within 5s, the harness logs cancel_drain_timeout and respawns

Expected behavior

A configurable inactivity timeout (e.g. idle_timeout or progress_timeout) should fail the turn if no tool calls, messages, or heartbeats are observed for N minutes, rather than waiting up to 2 hours.

Version and platform

• Buzz version: 0.5.14
• OS: macOS 26.5.2 (Apple Silicon)

Logs / additional context

Agent ran from ~16:54 to ~18:08 UTC (1h14m) on a single turn:

INFO  buzz_acp::queue: extending in-flight deadline by 7200s + 100s buffer
...
WARN  buzz_acp::acp: hard turn timeout exceeded (silence 5.001861875s)
WARN  buzz_acp: agent_returned — respawning (cancel-drain timeout) outcome="cancel_drain_timeout"

The agent kept renewing its deadline but never completed. Distinct from #5849 (process leak after cancel), which covers the cleanup side; this issue covers the detection side.

[mfethe1]

Same note as I left on #4434, for visibility: #5888 adds a persistent circuit-breaker health badge to the desktop Agents view, but it's derived entirely from SlotCircuit (crash/panic-triggered respawn) state, not turn progress. A stuck-but-alive turn — exactly the gap this issue describes — produces no signal from that badge; it would show the agent as healthy for the full 2-hour max_turn ceiling.

A configurable inactivity/progress timeout, as you propose, would need to live in buzz-acp's turn/queue tracking (where the existing extending in-flight deadline renewal logic already lives — see #4434 for a concrete incident with the same root shape, steer-driven deadline renewal with no completion). That's a different layer than what #5888 touches. Flagging so this doesn't get closed as addressed by the badge work — it isn't.