fix(buzz-acp): refresh idle clocks on turn completion and steer ack

[Stalker23b]

Fixes #7171

Problem

The idle-pool reaper clocks (idle-pool sleep, exit-after-inactivity) are refreshed only at dispatch time. Any turn that runs longer than the idle bound is guaranteed to look idle the moment it completes, so the first reaper tick after completion tears the pool down — killing the CLI process together with its live background tasks and pending wake-ups.

Observed in production: a 28-minute turn completed and the pool was reaped 13 seconds later, orphaning two background tasks whose completion the agent was waiting on (details in #7171).

Fix

Turn completion and steer acks now count as activity:

• The idle-clock refresh lives inside handle_prompt_result, so the existing unit tests around result handling also guard the wiring.
• The refresh decision is an exhaustive match on PromptSource: a new variant must explicitly decide whether its completion keeps the pool alive.
• Heartbeat results are excluded — heartbeat dispatch is gated on an idle slot with no flushable work, so counting them would keep a heartbeat-enabled pool awake forever.

Known edges (unchanged, noted for reviewers)

• The in-flight deadline is max_turn_duration + 100s; a turn exceeding it auto-expires and the pool can still be reaped before the turn ends (pre-existing).
• The panic path does not refresh the clocks (pre-existing).

Testing

• New unit tests: result_refreshes_idle_clock (mapping, exhaustive match) plus wiring tests that a channel result refreshes the idle clock through handle_prompt_result and a heartbeat result leaves it stale.
• cargo test -p buzz-acp: 28 failures on this (heavily loaded) machine, in modules this patch does not touch (acp::tests steer/session, pool::model_switch_tests, pool::startup_effort_tests) — the failure set is byte-identical on the clean base commit under the same conditions, i.e. pre-existing machine-local flakes, zero new failures from this patch. The four new idle-clock tests pass.
• Running in production across 18 agents since 2026-09-01: no premature teardowns after long turns.

🤖 Generated with Claude Code

[github-actions]

🔐 Codex Security Review

Status: review required for the current range.

The current range is 59328d5ae38a51a618dd2fddd7faf1343d42096f...91957a5493f44b2e5ef20ee00d5b62c503eba78e.
A new review must complete for this exact range. When manual authorization
is required, a Block organization member must comment exactly
@buzz-security-review 91957a5493f44b2e5ef20ee00d5b62c503eba78e to authorize a new review.
Any previous review applies only to its recorded range.

[salvatoremira1969-rgb]

Tested this PR on top of desktop-v0.5.23 on Windows 11 (Hyper-V VM, Claude runtime), same agent identity and environment in both runs, only the buzz-acp binary differs: with the release binary the pool was torn down 30 s after an 18-minute turn completed (900 s counted from turn start); with this PR applied the teardown came 906 s after turn complete and never earlier. No teardown during a turn in either run, both completion messages arrived. Details with UTC log lines: (#6378 (comment)). Works as described.