fix(terminal): tree-kill a hung bash probe on Windows instead of blocking forever in the post-timeout reap

[vatevstoil]

Problem

On Windows, the terminal tool's environment init can freeze an agent turn forever. Observed live in a Buzz/ACP deployment: the first turn calls the terminal tool, Creating new local environment for task default... is logged, and nothing ever follows — the probe bash.exe stayed alive for 7+ minutes and the turn never completed.

Root cause

_bash_starts() used subprocess.run(..., timeout=15). On Windows that construct is not hang-proof:

• on TimeoutExpired, run() calls Popen.kill() — which targets only the direct child; a wedged MSYS bash can survive it and/or leave grandchildren (conhost, probe children) holding the stdout pipe;
• run() then reaps with a timeout-less communicate(), whose reader-thread join() blocks until the pipe closes — i.e. forever.

py-spy of the hung process shows exactly that: run → communicate → _communicate → join with the probe bash still alive. Killing the probe's process tree by hand instantly unblocked the turn.

Fix

Replace subprocess.run with an explicit Popen:

• communicate(timeout=15) as before;
• on timeout, kill the whole process tree (taskkill /T /F on Windows, kill() elsewhere);
• reap with a bounded communicate(timeout=10), degrading to probe-failed instead of freezing.

A hanging probe now costs ~15s and marks the candidate as failed (the existing cache/fallback logic takes over) instead of freezing the whole turn.

Verification

Healthy path unchanged (probe returns in ~0.1s). The previously frozen Buzz/ACP deployment now completes terminal-using turns; the pathological case degrades gracefully.

🤖 Generated with Claude Code

[alt-glitch]

This was generated by AI during triage.

Duplicate of #69083. Both replace the Windows Git-Bash startup probe's unbounded post-timeout cleanup with bounded tree-kill and reap; #69083 is the earlier, broader implementation with retained-stdin coverage.