Mobile: DM messages omit recipient `p` tags, so ACP agents never receive them (desktop parity gap)

[sbenodiz]

Environment

• Buzz Desktop 0.5.4 (macOS 27.0), self-hosted relay wss://askie.communities.buzz.xyz
• Buzz mobile (Flutter), paired by QR to the same identity (eea98f63…) — verified same owner pubkey
• 8 buzz-acp agents, default subscribe=Mentions, respond_to=owner-only, no last_error
• Source read at block/buzz@631b05c (main, 2026-08-03)

Expected
A message sent to an agent's DM from the mobile app reaches the agent, exactly as the same message sent from the
desktop app does. messageMentionPubkeys.ts states the contract explicitly: "A DM addresses every other participant,
so it must carry recipient p tags even when the composer text contains no @mention. Agent harnesses and human
notification subscriptions both rely on those tags."

Actual
Mobile DM messages carry only [["h", <channelId>]]. buzz-acp subscribes with
{"kinds":[9,46010,40007],"#h":[channel],"#p":[agent_pubkey],"since":…} (crates/buzz-acp/src/relay.rs:3190-3196),
so the relay never delivers them. The agent is silent with no error anywhere — no log line, no last_error, nothing
in the UI. The message renders normally on every client, which makes it look like the agent is hung.

Root cause
desktop/src/features/messages/lib/messageMentionPubkeys.ts:12-29 branches on channel.channelType === "dm" and adds
p tags for all other participants. The mobile send path
(mobile/lib/features/channels/send_message_provider.dart:52-70) has no equivalent branch — it only tags explicit
mentions. send_message_provider.dart:75 is the sole outbound kind:9 path in the app.

Minimal repro

1. Run a buzz-acp agent with defaults (--subscribe mentions), DM it from Buzz Desktop → it replies.
2. Send the same text in the same DM from the mobile app → no reply, ever.
3. Inspect both events on the relay: the desktop one has ["p", <agent pubkey>], the mobile one does not.

Evidence (same author, same channel, same kind, same created_at — one answered, one ignored)

IGNORED   dbf339b5…  tags [["h","79c9f111-…"]]
ANSWERED  fa4c69bb…  tags [["h","79c9f111-…"],["p","73aff53a…"]]  → reply e1067774… 57s later

Reproduced again as a live A/B on 2026-08-04 05:00Z: the p-tagged event got the harness's 👀 accept-reaction and a
reply in 8s; the untagged one got neither.

Suggested fix
Port messageMentionPubkeys to send_message_provider.dart: when the channel is a DM, seed resolvedMentions with
the other participants' pubkeys before normalization.

Two smaller bugs found alongside

1. SendMessage.call does mentionPubkeys ?? _resolveMentions(content, channelId), but compose_bar.dart always
   passes a non-null (often empty) list, so _resolveMentions is unreachable from the composer. Typing @Name by hand
   without tapping the autocomplete silently produces no p tag. Desktop resolves typed names.
2. Mobile _buildReplyTags (send_message_provider.dart:146-160) emits only e tags; desktop's buildReplyTags
   (desktop/src/features/messages/lib/threading.ts:101-127) also emits ["p", authorPubkey] plus mention p tags.
   So replying to an agent from mobile also fails to wake it.

I searched block/buzz issues (gh-axi search issues "repo:block/buzz mobile DM mention p tag agent" and a second
phrasing) — 0 results, no existing report.

---