buzz-acp: hermes-agent ACP turns complete successfully but reply never publishes to the channel

## Bug Description

`buzz-acp` completes an ACP turn against a Hermes-backed agent (correct `stopReason: "end_turn"`, correct `session/update` `agent_message_chunk` events streamed) but the agent's reply never gets published back to the Buzz channel as a Nostr event. The channel shows the mention/prompt message but zero reply from the agent, in both the desktop UI and via direct relay query (`buzz messages get`).

## Environment

- Buzz Desktop version: **0.5.5** (macOS, Apple Silicon)
- Agent runtime: `hermes-acp` (Hermes Agent v0.20.0, ACP protocol v1/v2)
- Agent config: `runtime: hermes`, `respond_to: owner-only`, default `--agents 10` pool

## Steps to Reproduce

1. Create an agent in Buzz Desktop with `agent_command: hermes-acp`, `runtime: hermes`
2. Point it at a Hermes profile via the `HERMES_HOME` environment variable
3. Add the agent to a channel (`channels add-member --role bot`)
4. Send a message in the channel `@mention`-ing the agent, e.g. `@MyAgent In one sentence, what is your role?`
5. Wait for the agent's log to show the turn complete (`Turn ended: reason=text_response(finish_reason=stop) ... response_len=NNN`)
6. Query the channel's messages (`buzz messages get --channel ` or check the Desktop UI)

## Expected Behavior

A new `kind:9` message from the agent's pubkey should appear in the channel, containing the generated response text.

## Actual Behavior

No reply message appears — neither in the Buzz Desktop UI (confirmed visually: the mention message shows no reply/thread indicator) nor via `buzz messages get --channel ` (confirmed the channel's raw event list contains only the outbound mention messages, zero reply events, across multiple independent test sends and two separate Hermes-backed agents).

## Isolating Evidence — this is NOT a Hermes-side bug

To rule out a bug in Hermes' ACP server, we drove `hermes acp` directly over stdio (bypassing `buzz-acp` entirely) with a minimal hand-written JSON-RPC client, sending the same shape of `initialize` → `session/new` → `session/prompt` calls `buzz-acp` would send. Hermes responded correctly and completely:

```json
{"jsonrpc":"2.0","method":"session/update","params":{"sessionId":"...","update":{"content":{"text":"ACP","type":"text"},"sessionUpdate":"agent_message_chunk"}}}
{"jsonrpc":"2.0","method":"session/update","params":{"sessionId":"...","update":{"content":{"text":"_DIRECT","type":"text"},"sessionUpdate":"agent_message_chunk"}}}
{"jsonrpc":"2.0","method":"session/update","params":{"sessionId":"...","update":{"content":{"text":"_TEST","type":"text"},"sessionUpdate":"agent_message_chunk"}}}
{"jsonrpc":"2.0","method":"session/update","params":{"sessionId":"...","update":{"content":{"text":"_OK","type":"text"},"sessionUpdate":"agent_message_chunk"}}}
{"jsonrpc":"2.0","method":"session/update","params":{"sessionId":"...","update":{"size":1050000,"used":16643,"sessionUpdate":"usage_update"}}}
{"jsonrpc":"2.0","id":3,"result":{"stopReason":"end_turn","usage":{"cachedReadTokens":0,"inputTokens":14128,"outputTokens":8,"thoughtTokens":0,"totalTokens":14136}}}
```

The requested text (`"Reply with exactly: ACP_DIRECT_TEST_OK"`) was correctly streamed back chunk-by-chunk (`ACP` + `_DIRECT` + `_TEST` + `_OK`) with a valid final `stopReason`. This is the exact shape `buzz-acp` is supposed to consume and publish. The equivalent real Buzz-driven sessions logged the identical completion pattern (`Turn ended: reason=text_response(finish_reason=stop)`, non-zero `response_len`), so the same correct output was almost certainly available to `buzz-acp` in the real failing cases too — it just never became a channel message.

## Additional context from the agent's combined log

The log (Hermes + `buzz_acp` interleaved) shows nothing resembling an error around the point where the reply should be published — no `ERROR` lines, no relay-publish failure message, nothing. It simply goes quiet after the last `agent.conversation_loop: Turn ended` / `Auxiliary title_generation` lines. This suggests the failure is either a silent early-return, a swallowed exception, or a mismatch between what `buzz-acp` expects (protocol version, specific `session/update` shape) vs. what this Hermes version emits — worth checking whether ACP protocol v1 vs v2 (the log shows "Initialize from buzz-acp (protocol v2)" for the multi-agent pool but "Initialize from unknown (protocol v1)" for our direct test — Hermes may be negotiating a different protocol version than expected in the real Buzz flow) plays a role.

## Impact

Any Buzz agent configured with `runtime: hermes` (`agent_command: hermes-acp`) currently cannot post a visible reply to a channel, making this integration path non-functional for any multi-agent-persona workflow that relies on Buzz's own UI/relay for visibility (as opposed to only using Hermes' own logs to infer success).