buzz-acp: turn completes ok but reply is silently lost when the agent's buzz CLI write fails

A turn can complete "successfully" while the agent's reply is silently lost: if the agent's `buzz messages send` fails (observed: auth error, exit 3), the harness sees `end_turn` with `outcome=ok`, fires no failure notice, and requeues nothing. The human sees a mention with no response and no indicator.

Observed live (local relay, buzz-acp with `claude-code-acp`, kind:9 mention):

```
INFO acp::stream: …ails with an auth error (exit 3). The answer to the question is **14**, but I have no way to post it to the channel until…
INFO pool::prompt: turn complete for channel 85453cd6-…: end_turn
DEBUG buzz_acp: agent_returned agent=0 outcome="ok"
```

The agent computed the answer, reported its inability to post in its final text, and the harness treated the turn as ok — the failure classification from #1659/#2289 doesn't catch it because the ACP turn itself didn't error; only the out-of-band CLI write did.

What triggered the auth failure here is unconfirmed (transient; same env posted successfully in adjacent turns). The report is about the missing recovery path, not the auth error itself:

- The harness has no signal that a turn which was *supposed* to reply actually published anything. A cheap heuristic: turn ended `ok` + zero relay OKs for agent-authored channel events during the turn + triggering event was a mention → emit the existing failure notice (or retry once).
- Alternatively, surface CLI write failures back into the turn outcome so the existing dead-letter path applies.

Can take a PR for either direction if maintainers have a preference.