Mailing list subscribe/unsubscribe toggle (v3.11.0)

Add a subscribe/unsubscribe toggle to the mailing-list detail toolbar
(MailingListDetailView, which backs Lookup results and ProjectMailingListView).
Hidden for lists you own and while state is unknown.

State comes from membership in the subscriptions query, not
MailingList.subscription — live testing showed that field returns null even
right after a successful mailingListSubscribe, so it is a trap (documented in
ROADMAP API traps). The numeric listID the mutations require is read from
list(rid:){ id }. Verified live against ~hutch.

Bumps to 3.11.0 (build 96); roadmap/SCOPE corrected.

1 files changed, 5 insertions, 4 deletions

diff --git a/SCOPE.txt b/SCOPE.txt
index 8300d7b..490ad45 100644
--- a/SCOPE.txt
+++ b/SCOPE.txt
@@ -31,10 +31,11 @@
   unaffected because it filters on `ev.ticket_id`, which is why ticket timelines
   work. Nothing a client can do fixes this; revisit only if sr.ht changes the
   resolver.
-- ~~Subscribe to a mailing list~~ — **now buildable**. `MailingList` gained a
-  `subscription` field (confirmed live during the Q1–Q2 2026 ingest), so per-list
-  subscribe state is readable and `mailingListSubscribe` / `mailingListUnsubscribe`
-  can drive a real toggle. Moved to ROADMAP.txt ("mailing list subscribe").
+- ~~Subscribe to a mailing list~~ — **shipped** (v3.11.0). A subscribe/unsubscribe
+  toggle on the mailing-list detail view. State comes from the `subscriptions`
+  query (`MailingList.subscription` is a trap — it never reports your state; see
+  ROADMAP.txt API traps), and a list is reachable to subscribe to via Lookup or a
+  project's lists — no discovery API needed.
 - Submitting patches (a `git send-email` flow, not a GraphQL mutation; Hutch
   reviews patchsets but cannot send them)