feat(cli): peer list self-marking + send self-DM guard

closes the "DM looped back to my own inbox" footgun.

what was happening: peer list returns one row per presence,
including the caller's own session AND its sibling sessions.
the cli filtered out the exact-session row but left siblings
unlabeled — copying their pubkey from peer list silently
targeted your own sibling, and the message arrived in "your
own inbox" because the sender was you.

fix is two-part.

(1) peer list — tag rows whose memberPubkey matches the
caller's stable JoinedMesh.pubkey:
  ● displayName (this session) — the exact session running
                                 the cli call
  ● displayName (your other session) — sibling session of
                                       your own member
visually identical otherwise; just the marker.

(2) claudemesh send — refuse a target that exactly matches the
caller's own member pubkey on the mesh, with a hint pointing
at --self for the rare intentional sibling-DM case.

both changes additive — existing scripts that pass display
names or other peers' pubkeys behave identically.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

docs/roadmap.md

@@ -298,6 +298,14 @@ level, or wire claudemesh to messaging surfaces beyond Claude Code.
   default returns last 30d). CLI: omitting `--mesh` on each
   verb routes through the matching aggregator. *Shipped
   2026-05-03 in CLI v1.16.0.*
+- **v0.5.1 — peer list self-marking + send self-DM guard** —
+  `peer list` now tags rows from the caller's own member with
+  `(this session)` or `(your other session)`, so a paste from
+  `peer list --json` doesn't silently target your own sibling.
+  `claudemesh send` rejects targets that resolve to the
+  caller's own member pubkey unless `--self` is passed. Closes
+  the "DM looped back to my own inbox" footgun reported on
+  v1.11.0. *Shipped 2026-05-03 in CLI v1.17.0.*
 - **v0.3.2 — multi-session DM routing + broadcast self-loopback** —
   fixes two production bugs: (1) replies via `claudemesh send
   <from_id>` rejected with "no connected peer" when the sender's