Managed agents can't run the bundled buzz CLI after #4609 — all permission requests rejected under dontAsk

## Summary

After #4609 (`fix(acp): reject unattended permission requests`, commit `ad538bfb1`, merged 2026-08-05), desktop-managed agents whose runtime raises a `session/request_permission` for the bundled `buzz` CLI are **unconditionally denied** — every `buzz` invocation, including `buzz --help`, fails. Since `buzz` is the agent's only interface to the relay (reading channels, sending replies), an affected agent cannot perform its primary function.

## Report

An X user reported (screenshot relayed in the `buzz-bugs` channel): a managed agent ("Growth", Claude Code runtime, **Mode: dontAsk**) says:

> I can't reach the buzz CLI in this session — every `buzz` command (even `buzz --help`) is being auto-denied by permission settings, while other Bash commands go through fine. That blocks me from reading the channel history or sending a reply.

## Root cause

#4609 intentionally made the harness fail closed:

1. `bypassPermissions` removed from the `PermissionMode` enum (`crates/buzz-acp/src/config.rs`).
2. Managed sessions default to `dontAsk`.
3. `handle_permission_request` (`crates/buzz-acp/src/acp.rs`) now answers every `session/request_permission` with `reject_once` (or `cancelled`) instead of the old `allow_once` auto-approval.

The commit's operator notes predicted this exact failure:

> "Desktop managed agents do not set a permission mode, so they inherit `dontAsk`. The desktop has no permission prompt, so operations needing approval now fail with no in-app way to approve them."

Why only `buzz` is affected: the agent runtime (e.g. Claude Code) only raises permission requests for tool patterns not pre-authorized in its own local settings. Common shell commands are covered by the runtime's allowlist and never ask; the `buzz` sidecar binary is not, so every invocation asks — and the harness now rejects all asks.

## Impact

- **Severity: high** for managed agents on affected runtimes/configs — the agent is cut off from the relay entirely (cannot read, cannot reply), while appearing "online".
- The failure is confusing to end users: the agent blames "permission settings" with no in-app way to see or fix anything.

## Proposed fix (narrow, preserves fail-closed posture)

Pre-authorize the **bundled `buzz` CLI** for managed sessions, so the platform's own sidecar is never subject to the reject-all path, while all other permission requests keep failing closed. Candidate mechanism: seed the managed agent runtime's local pre-authorization (e.g. Claude's `settings.json` `permissions.allow` for `Bash(buzz *)` / the resolved sidecar path) at nest creation — #4609 explicitly scopes agent-side pre-authorization as outside the harness guarantee, so this does not reopen the auto-approval hole.

Longer term: a desktop permission prompt so `dontAsk` is not the only reachable mode (also called out in #4609's operator notes).

## References

- #4609 / commit `ad538bfb1e6bfebcb03afaf4dd4d22323e7e62bd`
- `crates/buzz-acp/src/acp.rs` — `handle_permission_request` / `permission_denial_response`
- `crates/buzz-acp/src/config.rs` — `PermissionMode`
- `crates/buzz-acp/src/pool.rs` — `apply_permission_mode`, `agent_supports_mode`