Publish successful ACP replies

[johncarle]

What changed

• accumulate visible agent_message_chunk text during each ACP prompt
• retain the successful turn's triggering batch long enough to preserve channel and thread context
• sign and publish the completed response as a kind-9 event from the managed agent identity
• keep replies flat in existing threads, p-tag the triggering author, and skip empty responses

Why

Successful managed-agent turns currently return the agent to the pool without publishing the generated text. Agents receive prompts and complete normally, but their replies never reach the relay or channel UI. Failure notices already have a signed publication path; successful responses did not.

This fixes the missing harness boundary while keeping signing keys inside the managed harness rather than exposing them to sandboxed agent subprocesses.

User impact

Managed ACP agents—including Hermes-backed profiles—will visibly reply in channels and DMs after successful turns. Threading and recipient notification metadata are preserved.

Validation

• cargo fmt --all -- --check
• cargo clippy -p buzz-acp --all-targets -- -D warnings
• cargo test -p buzz-acp (776 tests)

Added regression coverage for chunk accumulation, signed reply construction, existing-thread and top-level threading, author p-tags, and whitespace-only responses.

[Chessing234]

#5811 is the same change: same file, same AcpClient field accumulating agent_message_chunk text for the current prompt, cleared at prompt start, taken as a harness fallback reply. only the names differ (current_agent_response vs turn_agent_message). one of these should close.

if this one survives: #5811 carries unit tests on the accumulate/take cycle (including that a second prompt does not inherit the first prompt's text) and this branch does not. that is the behaviour most likely to regress silently, since the failure mode is republishing stale setup output rather than an error.

also relevant: #5819 attacks the same symptom from a third angle (promoting reasoning_content when content is empty), and #5732 is the report of the empty kind-9 events. worth deciding which layer owns "the turn produced no publishable text" before landing any of them.