comm: thread-subscribe / broadcast for group discussion threads

[ohdearquant]

Problem

Cross-actor thread READ already works: thread(id) filters by namespace + thread_id only (no actor filter), so any actor holding a thread id sees the full conversation. What is missing for a shared group-discussion thread is the notification plane:

• inbox only surfaces messages addressed to the calling actor, so participants are not notified of replies addressed to others — they must poll thread(id).
• send/reply target exactly one to_actor; there is no multi-recipient or thread-addressed delivery.

Requirements (from the group-discussion use case)

1. A message can notify ALL thread participants: either subscribe-to-thread (replies land in every subscriber's inbox) or a thread-addressed broadcast send.
2. Participation is joinable: an actor that has read a thread id can opt into its notifications.
3. Inbox entries carry the thread subject so a sweep can triage without a thread() round-trip.

Notes

• No channels/rooms abstraction wanted — the thread IS the room. Smallest verb surface that satisfies 1-3 wins.
• Interim (works today): participants poll thread(id) on a cadence; read is already cross-actor.
• Multi-agent group discussion over threads is a core product scenario for the messaging pack, not an internal-only need.

[ohdearquant]

Sub-requirement from the first live group-thread pilot (day one): thread(id) returns BOTH dual-write copies of every message (the outbound note and its inbound counterpart, linked by outbound_ref), so an N-message conversation renders as 2N entries. The thread view should deduplicate dual-write pairs (group by outbound_ref, prefer one canonical copy) — this is independent of the broadcast/subscribe feature and worth fixing first since it affects the read path that already works.