fix(relay): emit participant-addressed DM discovery

[ScaleLeanChris]

Summary

• emit the relay-confirmed kind:41001 event that buzz dms list already queries
• address every DM participant with a p tag
• preserve channel scope with d and h tags so the private-channel read gate applies
• emit on create, re-open, and immutable group-DM creation
• use the channel creation timestamp so retries and legacy self-healing produce one stable event

Root cause

The CLI discovery contract existed, but the relay had no kind:41001 producer. The relay emitted kind:39000 channel metadata and membership notifications, so the conversation appeared in buzz channels list while buzz dms list returned no conversations.

Verification

• rebased onto current block/buzz main at da818eddc2f470c006a1073c8c5452f8a989f272
• cargo fmt --all -- --check
• cargo check -p buzz-relay -p buzz-test-client --tests
• real local relay regression:
  • cargo test -p buzz-test-client --test e2e_nostr_interop test_dm_discovery_events_emitted -- --ignored --nocapture
  • result: 1 passed, 0 failed
  • proves creator and recipient discovery, one event after recipient re-open, complete participant and channel tags, and discovery by a newly added group-DM participant
• repository gate: just ci
  • result: passed
  • includes workspace and Desktop Clippy, Desktop and web checks/builds, Rust tests, Desktop Tauri tests (2684 passed, 18 ignored), and mobile tests (1552 passed)

Fixes #2897

Controlling work order: BAC-109

The relay already knows every participant, so DM discovery should not end as “Return to Sender.”

[mfethe1]

Reproduced this on macOS 15.6 (arm64) at head 5e419bea1, against a local single-node relay (Podman: Postgres 17, Redis 7, MinIO).

cargo test -p buzz-test-client --test e2e_nostr_interop \
  test_dm_discovery_events_emitted -- --ignored --nocapture

PR head: 1 passed, 0 failed (0.73s).

Negative control: I reverted only crates/buzz-relay/src/handlers/command_executor.rs and crates/buzz-relay/src/handlers/side_effects.rs to 5e419bea1~1, leaving your test file unchanged, then rebuilt the relay and restarted it against a freshly recreated database and Redis.

Without the implementation: 1 failed, at e2e_nostr_interop.rs:930:

assertion `left == right` failed: create plus re-open must leave one
kind:41001 event for creator; events: []
  left: 0
 right: 1

Restoring both files and rebuilding returned it to 1 passed (0.23s).

Zero kind:41001 events are emitted without the change, so the test discriminates the fix from its absence rather than passing either way — and it corroborates the stated root cause (no kind:41001 producer) rather than only exercising the new code path.

Also clean on the same head: cargo fmt --all -- --check, and cargo check -p buzz-relay -p buzz-test-client --tests (0 warnings, 0 errors).

Scope and limitations: single-node local relay, not a multi-instance or mesh configuration. I set BUZZ_GIT_CONFORMANCE_PROBE=false to bypass the S3/object-store startup gate, which is unrelated to DM discovery. The head was 63 commits behind main when I tested; I tested the submitted head as-is, without rebasing.