Windows Desktop: managed agents' first terminal command hangs for the full tool timeout (420s) in the buzz-acp context

## Summary
On Windows, a Desktop-managed agent (buzz-acp → Hermes Agent ACP harness) hangs on its **first `terminal` tool invocation for up to the full tool timeout (420 s)**, capturing only ~55 chars of output, then the tool times out. The exact same harness + config executed from a normal console completes the same terminal task in ~25 s. Turns end up taking 15-25 minutes because the model keeps retrying terminal commands.

## Environment
- Buzz Desktop v0.5.20 (Windows, Tauri), hosted relay (buzz.xyz communities, relay 0.2.1)
- Agent harness: Hermes Agent v0.20.6 spawned by `buzz-acp.exe` (agent pool), Windows 11 10.0.22631
- Model: zai/glm-5.3-flash

## Reproduction / observations
1. Start a managed agent from Desktop → Agents → Start.
2. DM the agent with an @mention. The turn dispatches fine (ACP prompt arrives, model responds).
3. As soon as the agent uses the `terminal` tool, the agent log shows:
```
API call #1 ... out=222
tools.terminal_tool: Creating new local environment for task session:...
... 420 seconds later ...
agent.tool_executor: sequential tool terminal timed out after 420.0s
agent.tool_executor: tool terminal completed (420.01s, 55 chars)
```
The deterministic "55 chars" partial output repeats across attempts, suggesting the spawned local shell never produces its ready/handshake output in this detached (no console, stdio wired to ACP pipes) context.
4. Control test on the same machine, same config, Hermes one-shot CLI (`hermes chat -q "run: echo ..."`) from a normal console: terminal tool completes, whole turn ~25 s.

## Impact
First turns of Desktop-managed agents on Windows take 15-25 minutes when any tool uses the terminal; the model often retries the terminal several times, multiplying the 420 s timeouts.

## Additional note
Agents also try to use the `buzz` CLI from the terminal to reply, but `BUZZ_PRIVATE_KEY` / `BUZZ_RELAY_URL` are not present in the terminal subprocess environment (fast auth failure instead of the hang). Passing those through the harness's terminal env would let CLI-based flows work; replying via plain assistant text already works and is preferable.

## Question
Is the buzz-acp agent spawn on Windows expected to give child tools a console/DETACHED_PROCESS environment that local-shell tools can use? If there is a recommended env/flag for the harness (e.g. console allocation, persistent-shell off), we'd love to configure it.

Happy to provide full agent logs if useful.