feat(relay): emit NOTICE when mentioned pubkey has no active connection (#1743)

[cameronhotchkies]

Summary

When a kind:9 channel message with p tags is successfully ingested, the relay now checks whether each mentioned pubkey has an active WebSocket connection in the community. If not, a NIP-01 NOTICE is sent back to the sender indicating the target appears offline.

This is Fix #1 from the #1743 scoping — giving senders immediate feedback that their mention may not be delivered in real-time.

How it works

1. Before the event is moved into the ingest pipeline, extract all p-tag pubkeys (deduped, sender excluded)
2. After successful ingest, check conn_manager.connection_ids_for_pubkey_in_community() for each pubkey
3. If the returned list is empty (no active WS connection on this pod), send a NOTICE:

   ["NOTICE", "offline: mentioned user <hex> appears to have no active connection"]
   

Constraints & trade-offs

• Pod-local only — if the target is connected to a different relay pod, the notice still fires. Acceptable for v1; a future enhancement could consult Redis presence.
• Lightweight — no Redis round-trip. Uses the existing in-memory connection manager which is O(n) over connections but typically small.
• Only kind:9 — no overhead added to other event types.
• Metric: buzz_mention_offline_notices_total counter for observability.

Testing

• cargo check -p buzz-relay ✅
• cargo clippy -p buzz-relay -- -D warnings ✅ (zero warnings)

Related

• Closes phase 1 of Agent @mentions silently fail when mentioned agent is offline #1743 (relay notice direction)
• Phase 1.5 (sender-side desktop warning) and Phase 2 (harness backfill) are separate PRs

[wesbillman]

From my agent...

The underlying silent-stall problem is real, but this implementation does not yet provide a reliable sender warning.

Blocking issues:

1. Every p tag is treated as an explicit mention. Buzz replies structurally include the replied-to author's p tag (desktop/src/features/messages/lib/threading.ts), so an ordinary reply to an offline author will produce a misleading “mentioned user” notice even when the message did not mention them. The wire format needs to distinguish explicit mentions from reply routing metadata (or this check needs to consume existing explicit-mention metadata).

2. The desktop sender drops NOTICE frames. RelayClientSession.handleWsMessage handles only AUTH, EVENT, OK, and EOSE; ACP only writes NOTICE to its warning log. Thus normal desktop users get no visible feedback, and sending agents do not receive a machine-actionable failure signal. Please wire the result into the sender UX/agent send path so this actually fixes #1743.

3. Presence is only pod-local and checks any authenticated connection, not a matching subscription/delivery. In a multi-pod deployment it can report an online recipient as offline; conversely, an unrelated authenticated socket can suppress the warning even when no harness subscription received the message. Please use authoritative cross-pod presence with semantics tied to the intended recipient/delivery guarantee, or explicitly narrow and prove the behavior.

Please also add focused relay/client tests covering accepted-only behavior, kind restriction, dedupe/self-exclusion, explicit mention vs reply-author p tags, online/offline cases, and visible handling of the notice. The current change adds no tests for this critical path.