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

## 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:

```bash
buzz messages send --channel --content ""
```

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

```text
event a1e61803c6bfca383d2326b11c3f8be0e6b16a06099b912654120bd0b66d73b8
```

Signed tags:

```json
[
["h", ""],
["auth", "", "", ""]
]
```

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.

Start at the `buzz messages send` entry point and trace the DM event builder and channel-membership data used for recipients. Add cross-client contract coverage for mobile-to-agent and CLI-to-mobile/Desktop sends; done means two-party DM events carry the other participant's `p` tag or use a documented symmetric delivery mechanism, with a warning or failure when no recipient is present.

Written by the indexing model from the issue text.