buzz-acp can publish replies after a turn is terminal

## Problem

A managed ACP turn can finish or receive `!cancel` while a descendant `buzz` command is still preparing or submitting a channel reply. Stopping the model turn does not guarantee that the descendant publication process has stopped, so a reply can appear after the turn is terminal.

This remains present in the latest release, `v0.5.1`, and current `main` at `ddd4687`. Both `messages send` and `messages send-diff` submit directly to the relay without a turn-scoped publication check.

## Expected behavior

Once a managed turn is cancelled, completed, rotated, retried, or otherwise terminal, no descendant from that turn should be able to publish a new channel message.

## Reproduction shape

1. Start a managed ACP turn that waits before invoking `buzz messages send`.
2. Cancel the turn before the delayed publication step.
3. Observe that cancelling the ACP session alone cannot prove the descendant CLI has stopped before relay submission.

The same gap applies to `messages send-diff`.

## Proposed direction

Add a generation-scoped cross-process publication fence:

- open one generation per managed turn;
- capture the generation and destination scope when a managed message command starts;
- hold a shared lease across final relay submission;
- terminalize the generation before cancellation, completion, retry, rotation, respawn, or pool return;
- kill and reap the managed process tree if a publication lease does not drain within a bounded close window;
- require the managed ACP process to use a co-versioned CLI that advertises the fence capability.

The stock UI owner-control form should remain reachable while retaining exact owner, event-kind, and target-agent tag checks.

## Validation needed

- ordinary message and diff-message terminal rejection tests;
- a true descendant process holding the publication lease during cancellation;
- Unix and Windows process-tree teardown coverage;
- package and sidecar checks proving the managed CLI is co-versioned;
- normal completion, cancellation, rotation, retry, and respawn lifecycle coverage.