DM events omit recipient p tags in both directions (mobile and buzz CLI replies)

[Dilosaurus]

Summary

Direct-message channel events do not automatically carry the other participant’s recipient p tag in either client direction:

• Mobile-originated DM messages omit p unless the user explicitly selects/types an @mention.
• buzz messages send replies into the same DM channel also omit the recipient p tag unless an explicit mention is added.

The events are accepted and persisted, but recipient notification / managed-agent wake behavior that depends on p silently does nothing. This creates a bidirectional DM reliability gap.

Sanitized mobile → managed-agent reproduction (2026-08-04 UTC)

In a two-party DM channel:

Event	Shape	Result
dc20114df128f7874a49753996a541fc3ebc10c0ca73f5d18e17d9812d24047f	h plus attachment metadata; no p	no managed-agent wake
50656e003aaef36b6d81e2a50ebb40809c5e5369fe89ba4ba209eec3ca5ef80c	h only; no p	no managed-agent wake
39780bc53c28d5359e6d4fefff13dde24a72da00a066e0c661d62702afc750c0	h + recipient p	immediate wake
b3503cf6ddb42b535cf8482b4ad662542819db63f45e5ef9aebd332c61c60941	h + recipient p	delivered into the active turn

The only material event-shape difference was the explicit recipient p tag added by mentioning the agent.

Managed-agent CLI → mobile/Desktop reproduction

A reply was sent with:

buzz messages send --channel <dm-channel-uuid> --content "<reply>"

The CLI returned accepted:true, and later history proved relay persistence:

event a1e61803c6bfca383d2326b11c3f8be0e6b16a06099b912654120bd0b66d73b8

Signed tags:

[
  ["h", "<dm-channel-uuid>"],
  ["auth", "<redacted>", "", "<redacted>"]
]

There is no recipient p tag. Local artifacts do not provide a definitive Desktop receive/render receipt, so I cannot claim the event was not rendered; the evidence does show that the CLI omitted the recipient tag and therefore provided no recipient-notification tag.

Expected behavior

For a two-party DM channel, clients should either:

1. Automatically add a p tag for every other DM participant, independent of visible @mention text, or
2. Use a documented DM delivery/notification mechanism that does not require p and works symmetrically across mobile, Desktop, and CLI.

If neither happens, the send result should not imply successful recipient delivery.

Impact

• Plain mobile DMs can persist without waking the managed agent.
• Agent CLI replies can persist without notifying the human recipient.
• Both senders see success and receive no warning that the recipient tag is absent.

Suggested fix

• Make the DM event builder derive recipient p tags from channel membership for every client surface.
• Add cross-client contract tests for mobile → agent and CLI agent → mobile/Desktop.
• Return final recipient_pubkeys / mention_pubkeys and warn or fail when a DM event has zero recipients.
• Add client-side receive/timeline/render receipts so persistence is not confused with delivery.

Related: #4668, #3591 and #2835 cover the mobile omission; this report adds the stock CLI reply parity gap and the bidirectional notification consequence. #2747 covers the ACP DM mention gate that makes missing tags operationally significant.