Windows managed Hermes ACP runtime hangs while creating the local terminal environment

On Windows 11, Buzz Desktop's managed `BuzzHermes` agent can receive a DM and start Hermes ACP successfully, but the turn then hangs when Hermes invokes its terminal tool. The Buzz UI remains on a status similar to:
```text
Ran terminal: buzz messages send --help
```
The command itself is not the point of failure: running the installed Buzz CLI directly returns immediately. The managed ACP runtime stalls before the terminal command completes, while creating the local terminal environment. In one reproduction, an orphaned `bash.exe` remained after its parent process exited.

A second related issue occurs when a new message arrives during the stalled turn: Buzz attempts `Steer`, but Hermes ACP does not advertise steering support. Buzz falls back to cancel+merge, cancelling the Hermes turn and reporting ACP `Internal error` with no response.

## Steps to reproduce
1. Run Buzz Desktop on Windows 11.
2. Use a managed agent configured as `BuzzHermes` with the Hermes runtime.
3. The managed agent configuration uses `buzz-acp` and launches Hermes ACP.
4. Send one owner-authored DM mention to the agent.
5. Allow the agent to process a request that invokes the terminal tool (for example, a local `buzz ... --help` diagnostic).
6. Observe that the run can remain at:
```text
Creating new local environment for task default...
```
7. If another message is sent while the turn is active, observe the `Steer` fallback and cancellation behavior.

## Expected behavior
- The managed ACP runtime should create the local terminal environment promptly and execute the command.
- Buzz CLI commands should be resolvable in the managed agent environment, or the harness should use the absolute Buzz CLI path.
- When the agent does not advertise ACP steering support, a new event should be queued rather than cancelling the active turn.
- Stopping or cancelling the managed agent should terminate the complete ACP child process tree, including Git Bash/MSYS descendants.
- A completed Hermes response should be published back to the originating Buzz DM.
-
## Actual behavior
- The run can remain stalled for several minutes at local environment creation.
- No `Session snapshot created`, `local environment ready`, or `tool terminal completed` line appears.
- A `bash.exe` child was observed with zero CPU usage after its parent process exited.
- When a second message triggers Buzz steering, the log reports:
```text
steer: no active_run_id and agent did not advertise _session/steering
falling back to cancel+merge
Cancelled session ...
Turn ended ... interrupted_by_user ... response_len=0
agent_returned ... code -32603 ... Internal error
```
- The direct installed CLI is healthy and returns usage immediately:
```text
C:\Users\clawl\AppData\Local\Buzz\buzz.exe messages send --help
```
## Version and platform
- Buzz version: 0.5.20
- OS: Windows 11
- Managed runtime: Hermes ACP
- Hermes ACP version: 0.20.4
- Model/provider: `openai-codex:gpt-5.6-luna`
- Managed ACP settings observed: `agents=10`, `subscribe=Mentions`, `dedup=Queue`, `meh=Steer`, `respond_to=owner-only`
-
## Logs / additional context
Relevant log sequence from the attached harness log:
```text
2026-08-27 15:07:31 [INFO] tools.terminal_tool: Creating new local environment for task default...
2026-08-27T05:08:29.465760Z WARN buzz_acp::acp: steer: no active_run_id and agent did not advertise _session/steering — falling back to cancel+merge
… omitted 14 diff line(s) across 1 additional file(s)/section(s)

Start at the tools.terminal_tool path that logs “Creating new local environment” and the buzz-acp entry points covering steering, cancellation, and child-process cleanup. Reproduce the managed Hermes ACP turn on Windows 11 using the supplied harness steps and logs. Done means terminal setup completes, unsupported steering queues the message, the full child process tree stops, and the response returns to the originating DM.

Written by the indexing model from the issue text.