feat(buzz-acp): make BUZZ_ACP_IDLE_POOL_SLEEP configurable per agent, or document why it must not be

## Request

`BUZZ_ACP_IDLE_POOL_SLEEP` decides how long an agent's pool survives process-wide silence before every cached session is destroyed. The Desktop sets it to 900s and reserves the key, so it cannot be set from **Edit agent → Advanced → Environment variables**:

```
the following env vars are reserved by Buzz and cannot be overridden: BUZZ_ACP_IDLE_POOL_SLEEP
```

There is no UI field either, so fifteen minutes is fixed for Desktop-managed agents.

I would like to raise it. If there is a good reason it must stay fixed, that is a fine answer — but it is not currently written down anywhere a user would find it, and the reserved-list comment (*"Desktop-owned pool lifetime policy"*) states the intent without the rationale.

## Why fifteen minutes is short for some workflows

Session state is not recoverable once the pool tears down. Nothing is summarised or carried over; the next message starts a new session which is handed only `BUZZ_ACP_CONTEXT_MESSAGE_LIMIT` thread messages as `[Thread Context]` (12 by default). So a fifteen-minute interruption during multi-agent work silently costs the accumulated session context, and the discipline it forces — take a summary before ever stepping away — has to be perfect, because the reset is unannounced.

An agent also cannot tell it happened: a fresh session receives the thread history as injected context, which is indistinguishable from retained memory from the inside. Only the harness log records it.

## The policy is already reachable through an unreserved sibling

Raising this because it seems more likely to be an oversight than a decision, and because it is the honest state of things:

```rust
let idle_pool_sleep_bound = if config.lazy_pool {
Duration::from_secs(config.idle_pool_sleep_secs)
} else {
Duration::ZERO
};
```

A zero bound means the reaper is never created. `BUZZ_ACP_LAZY_POOL` is **not** on `RESERVED_ENV_KEYS`, so setting it to `false` disables idle teardown without touching the reserved key — by making the window meaningless rather than changing it.

I have not adopted this, and would rather not: it makes the pool eager, which is the failure mode in #2631 (parallelism 24, ~14 GB), and it could be closed by reserving one more key at any time. Mentioning it because if the fifteen-minute window is genuinely load-bearing, this path arguably should be reserved too — and if it is not, exposing the value directly seems better than leaving a side door.

## What would help

Any one of these:

1. Remove `BUZZ_ACP_IDLE_POOL_SLEEP` from `RESERVED_ENV_KEYS`, with a sane floor if a minimum matters.
2. Add a field beside Parallelism in **Edit agent → Advanced**, the way parallelism is exposed while `BUZZ_ACP_AGENTS` stays reserved. That precedent seems to fit exactly.
3. Keep it fixed, and document why — including whether `BUZZ_ACP_LAZY_POOL=false` is a supported way to opt out or an oversight.

Related: #6378 reports the timer tearing down a session that was actively working. Different defect, same subsystem — a configurable window would not fix that one.

## Environment

Buzz Desktop 0.5.17, Windows 11, four managed agents, `buzz-acp` harness. Source read at `f88cda9`.