buzz-acp: turn ending with unpublished agent text produces zero signal (no relay message, no warning)

## Summary

When a `buzz-acp`-driven agent ends a turn with non-empty `agent_message_chunk` text but never makes a successful `buzz messages send` call, the turn ends with **zero signal** — no relay message, no warning, no failure notice. From the outside (Desktop's activity/observer view) it looks like the agent replied; on the relay, nothing was ever published.

This is not a claim that plain-text output is *supposed* to auto-publish — per `crates/buzz-acp/src/base_prompt.md` and `crates/buzz-acp/README.md`, the documented design is CLI-out (agent must explicitly call `buzz messages send`), and `agent_message_chunk` is telemetry only (`crates/buzz-acp/src/acp.rs`, handler logs via `tracing::info!` and returns `false` — never builds a kind:9). That design is fine. The gap is the **silence** when an agent doesn't follow it.

## Repro

1. Run any `buzz-acp`-wrapped agent with a system/persona prompt that (incorrectly, in our case, due to bad advice we gave it) tells it plain text is sufficient and it should never shell out to the `buzz` CLI.
2. `@mention` the agent with a question.
3. Observe: Desktop's activity/observer view shows a full, coherent plain-text reply as the agent's final turn output.
4. Query the relay directly: `buzz messages search --author --limit 5` — no corresponding event exists at all. The turn produced real content and ended with no error, no failure notice, nothing.

We reproduced this against three separate live agent instances (all `buzz-agent`-based, via `buzz-acp` + `buzz-dev-mcp`) on 2026-07-31; confirmed the missing publish both via `buzz messages search` and by comparing `created_at` timestamps against the triggering mention.

## Why this matters

The only existing auto-publish path is for failure notices (`post_failure_notice` in `crates/buzz-acp/src/pool.rs`) — i.e., the harness already has the concept of "tell the relay this turn didn't produce a real reply." That same mechanism (or a lighter-weight warning) just isn't wired up for the "turn produced text, but no publish call happened" case.

Practical impact: a misconfigured or momentarily-confused agent (e.g. bad persona/memory instructions, or an LLM that got confused about tool-call syntax) fails completely silently from an operator's perspective. There's no error to notice, no channel signal, nothing — you only find out by cross-checking the relay directly against what Desktop's UI shows, which most operators won't think to do.

## Suggested fix (not prescriptive — flagging the gap, not the implementation)

When a turn ends with non-empty accumulated `agent_message_chunk` content and no successful `buzz messages send` (or equivalent) was observed for that turn, emit something on the relay — either route it through the existing `post_failure_notice` path, or a new lightweight "turn ended without publishing" notice. Even a harness-level warning surfaced in Desktop's UI (distinguishable from a real published reply) would resolve the operator-visibility gap.

## Environment

- `buzz-acp` built from `main` @ github.com/block/buzz (release build, 2026-07-31)
- Agent harness: `buzz-agent` (via `buzz-acp` + `buzz-dev-mcp` as the attached MCP server)
- Relevant source pointers: `crates/buzz-acp/src/acp.rs` (`agent_message_chunk` handler), `crates/buzz-acp/src/base_prompt.md` (L65-67, publish contract), `crates/buzz-acp/src/pool.rs` (`post_failure_notice`, the only existing auto-publish path)

Start with crates/buzz-acp/src/acp.rs, especially the agent_message_chunk handler, then read crates/buzz-acp/src/pool.rs and its post_failure_notice path. Use base_prompt.md and README.md to confirm the CLI-out contract. Done means a turn with non-empty agent text and no successful buzz messages send produces a distinguishable relay notice or warning, while normally published turns do not.

Written by the indexing model from the issue text.