buzz dms list returns [] for an active DM participant (recipient can't discover the conversation)

## Summary

`buzz dms list` returns an empty array (`[]`) for a user who is an active participant in an existing DM conversation — even though the DM has real messages flowing and `buzz dms open` reports the conversation already exists (`created: false`). This makes it impossible for an agent to discover DM conversations it is a party to.

## Environment

- Repo: `block/buzz` @ `499c5d3` (`fix(relay): preserve reconnect backoff (#2759)`)
- `buzz-cli` built from source (`cargo build --release -p buzz-cli`)
- Relay: a hosted Block community relay (`*.communities.buzz.xyz`)
- Two participants: an agent identity ("Chip") and a human. The human initiated the DM from a Buzz client; the agent polls via `buzz-cli`.

## Steps to reproduce

1. Human user opens a DM with the agent's pubkey from a Buzz client and sends messages.
2. As the **agent** (recipient), run:
```
buzz dms list
# => []
```
3. Confirm the conversation actually exists and is reachable by the agent:
```
buzz channels list
# => includes {"channel_id":"","name":"DM","description":"","created_at":...}

buzz messages get --channel --limit 10
# => returns the real kind:9 DM messages, including ones authored by the human,
# each tagged ["p",""] and ["h",""]
```
4. Even explicitly (re)opening the DM from the agent side does not make it appear:
```
buzz dms open --pubkey
# => {"accepted":true,"dm_id":"","message":"response:{...,\"created\":false}"}

buzz dms list
# => still [] (retried repeatedly, no propagation delay involved)
```

## Expected

`buzz dms list` should return the DM conversation for **any** participant (initiator or recipient), so an agent can enumerate the DMs it belongs to.

## Actual

`buzz dms list` returns `[]` for the recipient, despite an active, message-bearing DM that is visible via `channels list` and `messages get`.

## Likely cause

`cmd_list_dms` (`crates/buzz-cli/src/commands/dms.rs`) queries **kind:41001** (relay-confirmed DMs) filtered by `#p = `:

```rust
let filter = serde_json::json!({
"kinds": [41001],
"#p": [my_pk],
"limit": limit
});
```

`buzz dms open` submits a **kind:41010** request with a `d` tag (`crates/buzz-cli/src/commands/dms.rs::cmd_open_dm`). The gap appears to be on the relay side: the **kind:41001 relay-confirmation event is either not emitted for the recipient, or is not `#p`-tagged with every participant** (only the initiator, or nobody), so the recipient's `#p` filter never matches. The kind:9 messages in the conversation *are* correctly `p`-tagged to the recipient, which is why `channels list` / `messages get` work while `dms list` does not.

So the DM data plane (messages) is fine; the DM **discovery** plane (kind:41001 confirmations queryable by `#p` for all participants) is missing/incomplete.

## Impact

Agents built on `buzz-cli` cannot reliably enumerate DM conversations. A poll-based integration that seeds "which conversations are DMs" from `dms list` will silently treat inbound DMs as regular channels (or miss them entirely), because the only reliable enumeration source (`channels list`) does not distinguish a DM from a channel — the DM shows up simply as `{"name":"DM"}` with no type/kind field.

## Suggested fixes (either or both)

1. **Relay:** ensure the kind:41001 relay-confirmed-DM event is emitted for a conversation and carries a `p` tag for **every** participant (initiator and all recipients), so `dms list`'s `#p` filter matches for all of them.
2. **CLI/API ergonomics:** expose a reliable way to distinguish a DM from a channel in `channels list` output (e.g. a `type`/`kind` field, or a `participants` array), so clients aren't forced to infer it from the display name `"DM"`.

Happy to provide raw event JSON (kind:9 tags, the `dms open` response, `channels list` output) or test against a specific relay build if useful.

Start in crates/buzz-cli/src/commands/dms.rs at cmd_list_dms and cmd_open_dm, then compare the kind:41001 #p query with the kind:41010 request and the events returned by channels list and messages get. Verify whether relay-confirmed DM events are emitted and tagged for every participant. Done means recipients can discover active DMs through dms list, or channels list reliably distinguishes DM conversations.

Written by the indexing model from the issue text.