buzz-acp: correctly p-tagged mentions accepted by relay never reach agent — persists across full VPS reboot, relay redeploy, and buzz-acp rebuild from latest source

**Describe the bug**
A buzz-acp managed agent (Codex via codex-acp, running as a systemd service on a self-hosted VPS) stopped receiving @mention events entirely. The agent had been working normally for roughly a day, responding correctly to mentions, before it silently stopped without any config change on our end. The relay accepts and correctly p-tags every message — verified via a raw nak subscription authenticated as the agent's own identity — but the agent's buzz-acp process shows zero corresponding log activity: no queue entry, no error, nothing. The client (Desktop or mobile) shows a brief "typing" indicator, then nothing, with no error surfaced to the sender.

This is not the transient reconnect-gap issue described in #4752. It persists even immediately after a fresh systemd restart (fresh subscription, no possible stale since filter), across a full VPS reboot, a full Railway relay redeploy, and a buzz-acp rebuild from latest main against an updated relay.

**Steps to reproduce**
Deploy a buzz-acp managed agent as a systemd service on a self-hosted relay, subscribed to a private channel (respond_to=anyone, subscribe=Mentions).
From a separate client (Desktop or mobile), send a plain-text @mention to the agent in that channel.
Observe: client shows a brief "typing" indicator, then no response.
Check the agent's journalctl output: no log line at all corresponding to the sent message.
Independently verify via nak, authenticated as the agent's own identity, filtered on the channel (#h): the message is present and correctly tagged, e.g.:
json
{"kind":9,"id":"...","pubkey":"","tags"

**Expected behavior**
A correctly p-tagged, relay-accepted mention event should reach a subscribed, online agent's buzz-acp process and trigger normal processing (queue entry, prompt, response). An agent that was previously responding correctly should not silently stop without any config change or visible error.

**Version and platform**
Buzz version: relay 0.2.1 (self-hosted on Railway, ghcr.io/block/buzz:latest); buzz-acp built from origin/main commit 2ac0aa1dd ("Collapse contiguous join messages #7262"); codex-acp v1.6.2
Server OS: Ubuntu (Hetzner VPS), agent run as a systemd service
Buzz desktop: v0.5.19 running on Windows 11

**Logs / additional context**
What was ruled out, in order:

Reconnect-gap loss (#4752): reproduced with zero WebSocket reconnects in the preceding log window, and immediately after a fresh restart.

Auth: direct codex "say hello" in the agent's exact environment (same CODEX_HOME, same API key) returns a normal response.

Relay-side tagging/storage: confirmed correct via raw nak query as the agent's own identity — event exists, correctly tagged, accepted.

Stale binary/relay version: reproduced after rebuilding buzz-acp from latest main against a freshly redeployed relay (version bumped 0.2.0 → 0.2.1 during troubleshooting).

Client-side mention formatting: reproduced with plain, unformatted @mention text.

Agent-specific config: reproduced on multiple independently-configured agents on the same relay (different pubkeys, different personas).

Example buzz-acp startup log immediately preceding a failed test (clean startup, no errors):

INFO buzz_acp: connected to relay at wss://
INFO buzz_acp: subscribed to membership notifications
INFO buzz_acp: agent owner:
INFO buzz_acp: discovered 2 channel(s)
INFO buzz_acp: subscribed to channel
INFO buzz_acp: presence set to online

No further log lines appear for this service despite multiple subsequent @mention events confirmed present on the relay via nak.

Happy to provide full redacted .env/config.toml and additional nak traces on request. Reproducible and consistent for approximately one week across the above troubleshooting steps.

Start with the buzz-acp startup and channel-subscription path described in the report, then reproduce the failure while comparing its logs with the authenticated nak subscription. Trace why correctly p-tagged events present on the relay produce no queue or processing activity. Done means subscribed online agents receive mentions and show normal queue, prompt, and response activity without silent drops.

Written by the indexing model from the issue text.