buzz-acp: is --permission-mode a gate, or a hint to the adapter?

## Is `--permission-mode` meant to be a gate, or a hint to the adapter?

`buzz-acp` offers `--permission-mode` / `BUZZ_ACP_PERMISSION_MODE` with six values
(`default`, `auto`, `acceptEdits`, `bypassPermissions`, `dontAsk`, `plan`;
`crates/buzz-acp/src/config.rs`), applies the value at `session/new` via
`session/set_config_option` when the adapter advertises it
(`pool.rs::apply_permission_mode`), and answers **every**
`session/request_permission` with `allow_once`
(`acp.rs::handle_permission_request`, documented as such in the read-loop comment).

For an adapter that delegates the decision to its client — `claude-agent-acp` does —
those two facts cancel out. The mode is applied, the adapter then asks about the very
tool calls the mode was meant to gate, and the harness approves them.

Concretely, with `BUZZ_ACP_PERMISSION_MODE=plan` (reachable today from the Desktop's
per-agent environment-variable editor, or by running `buzz-acp` directly), asking the
agent to create a file creates the file:

```
INFO buzz_acp::pool: applied permission mode "plan" on session 612666aa-…
[claude-agent-acp] task_summary: "writing business plan to Desktop"
```

So `plan`, `dontAsk` and `acceptEdits` end up behaving like `bypassPermissions`
unless the adapter happens to enforce them internally.

## The question

Is that intended — the modes are a hint passed to the adapter, and
`bypassPermissions` is the real contract the harness guarantees? If so the flag's doc
comment could say it, and it would be clear that these values are best-effort.

Or is it a gap, and the harness should honour the read-only modes at its own seam?

## What we have, if the second answer is the right one

We run a fork and hit this while exposing the modes in the UI, so we have a patch
ready and would send it as a PR if the direction fits:

- sessions created under `plan` / `dontAsk` are marked read-only and
`handle_permission_request` answers `reject_once` for them;
- one exception, or the agent goes mute: tool calls whose command starts with
`buzz ` — the agent's own CLI, how it reads the thread and posts its reply;
- a refused `ExitPlanMode` ends a Claude Code turn silently ("STOP what you are doing
and wait for the user"), so the base prompt tells the agent to post the plan with
`buzz messages send` instead of calling it.

Tests drive `handle_permission_request` over a scripted stdio adapter, so removing
the guard fails them.