fix(acp): kill the agent's whole process tree on Windows

[Chessing234]

Fixes #5849.

AcpClient::shutdown kills the child's process group — the child is spawned with process_group(0), so its PID is its PGID and killpg takes the harness's own workers (MCP servers, tool subprocesses) down with it. That path is #[cfg(unix)]. On Windows kill_process_group returned false unconditionally, so the caller fell back to child.start_kill(), which ends the direct child and nothing below it.

Every cancel-drain timeout therefore leaked a tree. The report has 20 hermes-acp.exe and 42 python children under one buzz-acp, spawned in a five-second burst, none of them exiting — and the respawn path is working exactly as designed on top of that, which is why the count grows with each failed turn rather than stabilising.

This adds the Windows branch: taskkill /PID <pid> /T /F. /T is the tree, /F is unconditional — a drain timeout means the agent already ignored a polite stop. The job-object API would be the more elegant answer, but it needs unsafe, and this crate is #![deny(unsafe_code)]; taskkill ships with every supported Windows and needs no privilege beyond the one already required to kill the child. The non-Unix non-Windows fallback keeps its old behaviour.

Verified: cargo clippy --workspace --all-targets -- -D warnings clean, cargo fmt --all --check clean, cargo test -p buzz-acp --lib 779 passed. The cfg(windows) code is type-checked for x86_64-pc-windows-msvc (I installed the target and compiled the branch in isolation — the crate itself cannot cross-compile here because a C dependency needs the MSVC toolchain), and the flags are asserted from a pure command-builder that runs on every platform. Not run: an actual Windows machine. I have no Windows host, so the behavioural claim rests on taskkill's documented semantics, not on my having watched the tree die.

[themiguelamador]

Requesting changes for two Windows process-lifecycle issues:

1. High — executable search-path hijack. Command::new("taskkill") supplies a bare executable name. Windows CreateProcess search order checks the application directory and the parent process's current directory before the system directory. Because the ACP harness commonly runs with an agent-controlled repository as its current directory, a repository containing taskkill.exe could execute arbitrary code as the Buzz user whenever an agent shuts down or is replaced. Microsoft recommends a fully qualified path for CreateProcess-style launches. See CreateProcess executable search order and Microsoft's search-path security guidance.
2. Medium — synchronous process execution inside async shutdown. .status() blocks until taskkill exits, but AcpClient::shutdown calls it directly on the Tokio worker before entering the existing five-second child-wait timeout. A stalled system command can therefore pin an executor thread indefinitely and evade the shutdown bound entirely.

I fixed both in 37a1c7679: taskkill.exe is resolved beneath an absolute SystemRoot\\System32 (otherwise the existing direct-child fallback is used), and async shutdown moves the synchronous command to the blocking pool with its own five-second bound. The /T and /F behavior remains consistent with Microsoft's taskkill contract.

Verification:

• cargo fmt --all -- --check
• cargo test -p buzz-acp --lib — 779 passed
• cargo test -p buzz-acp --lib process_tree_kill_tests
• cargo clippy -p buzz-acp --all-targets -- -D warnings
• git diff --check

I also attempted the installed x86_64-pc-windows-msvc target check; as noted in the PR, this macOS host cannot complete the crate because native crypto dependencies require unavailable Windows SDK headers. The platform-neutral command construction is covered by the regression test, but behavior still needs a real Windows validation run.

[Chessing234]

Both fixed, one commit each. 37a1c7679 wasn't reachable (Complear/buzz 404s), so these are written from your description.

1. Search-path hijack. Agreed, and thanks — the current directory being an agent-controlled repository is exactly what makes this reachable. taskkill.exe is now resolved beneath an absolute %SystemRoot%\System32, and a SystemRoot that is missing or not absolute returns None so the existing direct-child fallback runs: leaking the tree is bad, running an attacker-placed binary is worse.

One deliberate difference from a plain Path::is_absolute check — taskkill_program_in tests for a drive-rooted or UNC path by Windows' own rules, as a string. That way the guard is exercised by the suite on macOS and Linux too, rather than only on a Windows runner:

C:\Windows      -> C:\Windows\System32\taskkill.exe
\\host\share\win -> \\host\share\win\System32\taskkill.exe
Windows, ..\Windows, \Windows, /usr/bin, "" -> None

2. Blocking call in async shutdown. Right — the .status() call sat before the five-second child-wait and could pin an executor thread past it. kill_process_group_async puts the Windows path on the blocking pool under its own five-second bound, and a timeout there falls back to start_kill(). Unix keeps calling killpg inline since it returns immediately. Drop still uses the sync form as it can't await. The match guard couldn't host the .await, so that call site is now a let plus an if.

On Windows validation — same limit you hit: cargo check -p buzz-acp --target x86_64-pc-windows-msvc dies in cc-rs looking for lib.exe. To get some coverage of the cfg(windows) bodies I temporarily compiled copies of them unconditionally under cfg(test) and ran clippy; they type-check and lint clean on this host. That is not a substitute for a real Windows run, and the runtime behaviour of taskkill still needs one.

Verification:

• cargo test -p buzz-acp --lib — 781 passed
• cargo test -p buzz-acp --lib process_tree_kill — 3 passed
• cargo clippy -p buzz-acp --all-targets -- -D warnings
• cargo fmt --all -- --check