feat(matrix): cross-context call awareness notification

[rozagerardo]

Context

Split out from #2383 (call UX improvements, closed). No mechanism today notifies a user of an
active call while they're on a different context — a signal/DM thread, or a different signal than
the one with the call.

Two existing mechanisms, neither covers this case:

• The in-call dock overlay only shows once you're already in a call and navigate away.
• The join-hero banner is room-scoped only — doesn't fire on a signal thread, doesn't surface a
  call in a different signal.

Requirements confirmed with Alex Prate:

• Notify across contexts: room call visible while on a signal; signal call visible while on a
  room or a different signal.
• Must not double-notify a user already on a call.
• Must be more subtle than the current full-overlay call-notification style — exact surface
  (badge / toast / thin banner) is an open design question to resolve during scoping.

What this involves

• Short discovery pass on notification surface design (subtle badge vs. toast vs. banner).
• Determine what call-membership state for rooms/signals the user isn't currently viewing is
  already synced client-side vs. needs a new subscription.

Depends on

• feat(matrix): migrate group calls to MatrixRTC + LiveKit SFU #2361 (MatrixRTC + LiveKit SFU migration)
• feat(matrix): video call improvements — PiP, screenshare layout, sound isolation, recording, cross-context awareness #2383 (call UX improvements — origin issue, closed)

Open questions

• Badge, toast, or thin banner for the cross-context notification?
• Is call-membership state for non-active rooms/signals already synced client-side?

[rozagerardo]

Design-discovery note (2026-07-29), following up on the discovery pass discussed with Alex.

Confirmed: room calls and signal calls run through the same mechanism (one MatrixRTC + LiveKit call session, bound to whichever Matrix room id is current). Signals turned out to be their own dedicated Matrix rooms (coherences.room_id), not threads inside a space's room — this is a real divergence from docs/requirements/voice-video-call-matrix-tech-spec.md's "Signal = Thread" v1 design, worth a doc correction pass separately.

Good news on implementation cost: this app already runs a full, unfiltered account-wide Matrix /sync (no filter/lazyLoadMembers configured). That means call-membership state (m.call.member, MSC4143) for every room the user has joined — every space, every signal — is already arriving client-side and sitting in the SDK's in-memory store today; nothing currently reads it outside the single active-room hook. So this feature is "add a listener over data we already receive," not "open new subscriptions per room."

Looked into whether Matrix's Sliding Sync (MSC3575 → MSC4186 "Simplified Sliding Sync") changes this calculus — it doesn't, and isn't a fit for this ticket regardless: it solves the opposite problem (reducing what's synced for accounts with huge room counts), would require a whole-client sync-mode swap (not additive/scoped), and our homeserver (Dendrite) has no native support — it's in maintenance mode/unfunded, and the only implementation PR, element-hq/dendrite#3673, is open but large (152 files/~20k lines) and blocked on maintainer review capacity plus its own fork dependency, so no reliable timeline. Flagging for visibility since it's a reasonable question to ask, but not pursuing it here — the current full-sync model already gives us what we need for free.

Remaining open item: the notification surface itself (badge / toast / thin banner) — still needs your input on which reads as "subtle enough."