[Bug] buzz-acp agents can still publish literal \n after #2121

**Describe the bug**

A managed OpenCode ACP agent can publish multiline replies containing literal backslash-`n` sequences (for example, `\n\n`) instead of real newline bytes. Buzz Desktop then correctly renders those characters literally.

PR #2121 added prompt guidance telling ACP agents to use stdin and warning that quoted `\n` is published literally. The failure still occurs in Buzz Desktop 0.5.5, so the guidance-only mitigation is not reliable for every ACP runtime or turn.

**Steps to reproduce**

1. Configure a managed OpenCode agent with the ACP command `opencode acp`.
2. Mention the agent in a channel and request a response containing multiple paragraphs or list items.
3. Let the agent publish its response through `buzz messages send`.
4. Inspect the resulting channel message and its relay event content.

Actual result: some replies display literal `\n\n`; the relay event already contains backslash and `n` characters rather than newline bytes.

**Expected behavior**

ACP-published multiline replies should contain real newline bytes and render as separate paragraphs or lines.

The fix should preserve intentional backslashes in code and prose. A global client-side unescape would therefore be unsafe. A harness/CLI-side validation, structured publishing path, or another deterministic safeguard may be more reliable than prompt guidance alone.

**Version and platform**

- Buzz Desktop: 0.5.5
- OS: macOS
- ACP runtime: OpenCode via `opencode acp`

**Logs / additional context**

Sanitized runtime evidence confirms the managed agent launched through `opencode acp`, connected to the relay, and reached online presence before publishing the affected response.

Source inspection indicates the literal characters exist before rendering:

- `crates/buzz-cli/src/commands/messages.rs` forwards supplied message content without converting escaped sequences.
- `crates/buzz-sdk/src/builders.rs` stores that content directly in the event.
- `desktop/src/features/messages/lib/formatTimelineMessages.ts` passes event content into the rendered message body.
- `desktop/src/shared/ui/markdown/nodeCache.ts` correctly handles real newline bytes through the Markdown pipeline.
- `crates/buzz-acp/src/base_prompt.md` documents the stdin workaround added by #2121.

This appears to be a recurrence or incomplete mitigation of the behavior addressed by #2121, rather than a Markdown rendering defect.

---
[aidevops.sh](https://aidevops.sh) v3.32.226 plugin for [OpenCode](https://opencode.ai) v1.18.9 with gpt-5.6-sol