Proposal: implement the `send_dm` workflow action (WF-07 TODO)

[SeanGearin]

What

crates/buzz-workflow/src/executor.rs:582 carries a maintainer TODO:

SendDm { to, text: _ } => {
    warn!(run_id = %run_id, step = step_id, "SendDm not yet implemented (to={to})");
    // TODO (WF-07): emit DM event.
    Err(WorkflowError::NotImplemented("SendDm".into()))
}

The send_dm action is already part of the workflow schema (ActionDef::SendDm
in schema.rs, documented as "Recipient — pubkey hex or {{trigger.author}}"),
already flows through template resolution (resolve_step_templates), and any
workflow that uses it today fails at dispatch with NotImplemented.

I would like to implement it, scoped to send_dm only (the neighbouring
SetChannelTopic TODO at :588 is left for a separate change).

Proposed design — reuse the two patterns the codebase already establishes

1. Emission path: mirror the sibling SendMessage arm exactly.
   The executor loads the run + workflow (community-scoped) to get the owner
   pubkey, then calls a new ActionSink::send_dm method. The relay-side
   RelayActionSink builds a kind:9 event, signs it with the relay keypair,
   attributes the workflow owner via a p tag, persists via
   insert_event_with_thread_metadata, and dispatches post-persist side
   effects via dispatch_persistent_event — byte-for-byte the same flow as
   send_message in crates/buzz-relay/src/workflow_sink.rs.

2. DM encoding: Buzz DMs are not NIP-17 wrapped events — they are private
   channels (channel_type='dm') opened idempotently by participant-set hash
   (buzz_db::dm::open_dm, the same path the kind:41010 handle_dm_open
   command handler uses). send_dm opens (or reuses) the owner↔recipient DM
   channel and posts the kind:9 into it. When the open creates a new channel,
   the post-create side effects of handle_dm_open are mirrored (membership
   cache invalidation, dm_created system message, group discovery events,
   membership notifications); on re-open, the owner's NIP-DV visibility
   snapshot is refreshed.

The recipient is additionally p-tagged on the message event, because agent
wake (event_mentions_agent in buzz-acp) and push delivery are p-tag gated —
a DM that does not wake its recipient would be dead on arrival.

Decisions flagged for maintainers

• Whose key signs a workflow DM? This implementation follows the pattern
  send_message already establishes: the relay keypair signs, the workflow
  owner is attributed via p tag, and the DM channel participant set is
  {workflow owner, recipient}. If the intent for WF-07 was instead
  owner-key-signed events (or a dedicated workflow identity), the sink method
  is the single place to change.
• Self-DM (to == workflow owner) is rejected as invalid input rather than
  creating a 1-participant channel (create_dm requires ≥2 participants).
• Privacy: unlike SendMessage, the DM body is not written to relay logs.

Tests

• Pure unit tests for recipient normalization (hex, npub, uppercase,
  whitespace, malformed, unresolved-template literals) following the existing
  resolve_send_message_channel test pattern in executor.rs.
• A Postgres-gated (#[ignore]) integration test in workflow_sink.rs
  mirroring workflow_send_message_p_tags_mentioned_member: asserts channel
  type/visibility, both p tags, idempotent channel reuse across sends, and
  self-DM rejection.

I've put the implementation up as draft PR #2614 for reference. Per
CONTRIBUTING's guidance to open an issue first for significant changes, I'm
keeping it in draft and treating this issue as the place to settle the design —
especially the signing-key question above — before it goes up for review.

[Wirenut33]

One live use case is worth including in the self-DM decision: a scheduled
workflow owned by a managed agent may target that same agent's pubkey to wake it
for a read-only monitor run. In that case {workflow owner, recipient} collapses
to one participant, so rejecting self-DM leaves the scheduled workflow unable to
wake its owner.

During a bounded self-hosted Buzz test, a relay-to-recipient automation DM worked
for this case when the relay signed the kind-9 event and the event carried:

• p=<recipient> for the ACP mention-gated wake
• actor=<workflow owner> for attribution
• buzz:workflow=true for recursion prevention
• h=<relay/recipient DM> plus discovery and recipient visibility refresh

The PostgreSQL integration regression for that experimental path passed at
Wirenut33/buzz@acff9cc2c5dc3ffd5d3136739aeed0ac009c6fe0. I removed the
implementation from #4234 because #2614 already owns send_dm; this comment is
only to make sure the self-wake requirement is considered before its participant
and signing semantics are settled.