buzz-acp: bound ACP session + provider-resource lifecycle (no eviction today)

### Background

Split out of the thread-scoped ACP sessions PR (#6732) review (reviewer P1).
Not introduced by that PR — it is a pre-existing lifecycle-hardening concern
that thread scoping makes more visible because it multiplies the number of
live sessions (one per thread instead of one per channel).

### Problem

Sessions are retained indefinitely:

- The pool's per-scope maps in `buzz-acp` (`sessions`, `turn_counts`,
`core_sections`, `canvas_sections`, `deliveries`, `session_owners`) have no
time- or size-based eviction. They only shrink on explicit triggers
(`!rotate`, channel/membership removal, agent exit/panic). Under thread
policy a busy channel can accumulate one entry set per thread and never
release them.
- `buzz-agent` sessions can retain their `McpRegistry` resources. A finite
`BUZZ_AGENT_MAX_SESSIONS` exists but defaults to unlimited.
- ACP has no obvious per-session **close** contract, so deleting only the
Buzz-side session IDs would not reliably release provider-side resources
(subprocesses, MCP servers, model context).

### Why it isn't a clean PR-local fix

A partial eviction (dropping Buzz-side IDs) would leak provider resources
and give a false sense of boundedness. This needs a designed lifecycle:

- an idle-TTL and/or LRU cap on pool scope maps, keyed by `SessionScope`,
- a real per-session close/teardown contract that releases provider resources
(ACP session close, `McpRegistry` teardown),
- a sensible finite default for `BUZZ_AGENT_MAX_SESSIONS`,
- metrics/telemetry for live-session count and evictions.

### Acceptance (proposal)

- Bounded live sessions per agent under sustained multi-thread load.
- Evicting a session provably releases provider-side resources.
- Defaults are safe for the default `channel` policy (no behavior change) and
bound growth under `thread` policy.

### References

- PR #6732 (thread-scoped ACP sessions)
- `crates/buzz-acp/src/pool.rs` (scope maps, `invalidate_*`)
- `buzz-agent` `McpRegistry`, `BUZZ_AGENT_MAX_SESSIONS`

Start with crates/buzz-acp/src/pool.rs, especially the scope maps and invalidate_* paths, then trace buzz-agent's McpRegistry and BUZZ_AGENT_MAX_SESSIONS handling. Define the session close and eviction behavior before implementation. Done means bounded sessions under sustained thread-scoped load, provider resources released on eviction, safe defaults, and live-session and eviction telemetry.

Written by the indexing model from the issue text.