Add a channel-level "Start new work" action for multi-agent sessions

## Problem

Buzz keeps ACP sessions scoped per agent and channel. That is a useful model for persistent project/topic channels, but a channel containing multiple agents has no user-facing way to begin a clean unit of work for the whole roster.

The existing `!rotate` control command is a low-level, owner-authorized primitive that targets one mentioned agent. For a channel with several agents, starting a new bug fix or feature currently means either:

- rotating every agent individually;
- creating another channel and rebuilding its roster; or
- continuing with old ACP session context.

This makes a persistent topic-channel workflow unnecessarily cumbersome, particularly when the agents are distributed across several launchers or devices.

## Proposed experience

Add a channel-level action such as:

- `/new ` in the composer; and/or
- a **Start new work** action in the channel menu.

The action should:

1. Discover the compatible managed-agent identities currently assigned to the channel.
2. Rotate each agent's ACP session for that channel.
3. Keep agent identities, keys, runtimes, launchers, and channel memberships unchanged.
4. Preserve lazy startup: rotating an idle agent should not require eagerly starting inference.
5. Create a visible root message or thread that marks the new work boundary.
6. Optionally initialize or refresh the channel canvas from a work template.
7. Report per-agent success or partial failure.
8. Never deploy or mint replacement agent identities.

## Intended workflow

A user could keep persistent channels such as `backend`, `frontend`, or `infra`, each with a stable multi-agent roster. When beginning sequential work in one of those topics:

```text
/new fix session expiry after login
```

Buzz would start fresh ACP sessions for the agents in that channel and open a visible work thread. Concurrent implementations would still use separate channels because agent session state is channel-scoped rather than thread-scoped.

## Authorization and compatibility

Session rotation should retain the authorization guarantees of `!rotate`. Only the agent owner, or another explicitly authorized role/capability, should be able to reset an agent's session.

The operation should target only agents that advertise or otherwise support session rotation. A relay-visible external agent should not be assumed to support Buzz ACP control commands merely because it has an agent profile.

## Related work

- #3871 proposes full configurable orchestration workflows. This request is intentionally narrower: a first-class work/session boundary for an existing channel roster.
- #5342 proposes persisting and resuming channel sessions. Explicit **Start new work** should invalidate any persisted receipt in the same way an intentional `!rotate` does.

## Contribution

I am willing to help implement this if the maintainers agree with the direction and can provide guidance on the preferred UX and protocol shape.

Start by tracing the existing `!rotate` control path and the ACP session handling for channel-scoped agents. Define the preferred `/new` or channel-menu entry point, authorization and capability checks, lazy rotation behavior, visible work boundary, partial-failure reporting, and canvas handling; done means the agreed workflow preserves identities and memberships while starting fresh sessions for supported agents.

Written by the indexing model from the issue text.