fix(matrix): active-call redirect crash + stale active-call-elsewhere notification

[rozagerardo]

Context

Clicking the "active call in " avatar in the right panel (the pulsing phone badge shown when another space has a live call) redirects into that room, but the app then crashes with Application error: a client-side exception has occurred. Previously reported and thought fixed; recurring, likely a regression from the #2424 / #2456 cross-context call-awareness work.

Repro

1. Have an active call running in Space A (e.g. "ger test signal 01").
2. While viewing a different space/room, click the active-call avatar badge in the right panel.
3. App navigates into the room, briefly shows the "active call in current space" popup, then crashes to the Next.js client-side error boundary.
4. Secondary repro: dismissing the "Not now" popup on the overlay can also trigger it.

Console evidence

• Repeated (dozens of) GET /api/v1/matrix/rooms/:roomId/signal → 404 Not Found for the room's Matrix room ID, looping without settling.
• GET /api/v1/signals/coh-<id> → 403 Forbidden (second repro, after dismissing "Not now").
• Uncaught Error: Minified React error #310 (rendered more/fewer hooks than previous render), thrown from a useMemo inside the right-panel/call-dock component tree.
• Also noisy but likely unrelated: repeated 404s on .../select-activate-action?_rsc=... (RSC prefetch for a parallel route).

Suspect area (from a quick look, not a full root-cause)

• packages/epics/src/common/human-chat-panel/resolve-signal-thread-by-matrix-room.ts — calls /api/v1/matrix/rooms/:roomId/signal.
• apps/web/src/app/api/v1/matrix/rooms/[roomId]/signal/route.ts — findCoherenceByRoomId returns null for a room the Matrix client considers actively in-call (idle-room-participants:synced fires for the same room ID), suggesting a data/lookup mismatch rather than a real "no signal" case.
• packages/epics/src/common/human-chat-panel/use-call-membership-registry.ts — the identity-resolution effect re-fires repeatedly instead of settling into sharedUnresolvedRoomIds, which is what's driving the 404 flood.
• The React Setup recommended extentions #310 crash is likely a hook-order issue in whatever component re-renders as this unresolved/loading state changes (right panel or the global call dock overlay — global-call-dock-overlay.tsx / human-right-panel.tsx both call resolveSignalThreadByMatrixRoom directly too).

Depends on / related

• feat(matrix): cross-context call awareness notification #2424 (closed) — cross-context call awareness notification, where this redirect flow was introduced.
• fix(matrix): multi-tab call identity + decouple messaging sync from single-tab leader lock #2456 (closed) — prior multi-tab call identity fix in the same area.

Open questions

• Why does findCoherenceByRoomId 404 for a room with an active MatrixRTC session — data mismatch (roomId format/casing) or a genuine missing coherence record?
• Is the repeated-fetch loop a caching/effect-dependency bug in use-call-membership-registry.ts, or are the direct callers in human-right-panel.tsx / global-call-dock-overlay.tsx bypassing that cache entirely?
• Is the React Setup recommended extentions #310 crash caused by this unresolved state, or a separate hook-order bug surfaced once the retry loop runs long enough?

Possible overlap: right-panel mount/unmount + elsewhere-call state (#2470 D18)

While working on #2470 (notification service redesign), we scoped a minimal change to make
the right-panel trigger always visible in the navbar (D18, implemented) but explicitly deferred a
larger version — persistent panel mount (not torn down when leaving a space) and a cross-space
aggregated unread/call-state — specifically because of previously-observed mount/unmount bugs in
this exact area (ConnectedHumanRightPanel's hasOpened teardown logic, tied to
useIsSpaceContext).

This bug's suspect area (use-call-membership-registry.ts's unresolved-state effect not settling,
a hook-order crash in the right-panel/global-call-dock component tree) sits squarely in that same
mount/unmount + elsewhere-call surface. Worth considering, once root-caused, whether the fix here
is a targeted patch vs. whether it's better folded into that broader redesign — the same fragile
lifecycle may be the root cause of both. Not a conclusion, just a flagged connection for whoever
picks this up.

See: hypha-context/progress/members/gerroza/tickets/2470-notification-service-redesign/decisions.md D18.

Scope addition: navbar still notifies about the call you're already in

Repro (reported): join a call in a space (PiP active), navigate away to a non-space page (e.g.
Networks) — the navbar's active-call-elsewhere badge keeps pulsing as if there's a different
active call to join. Opening it shows the same call you're already in via PiP.

Believed to have worked correctly before (not showing your own in-progress call as an "elsewhere"
notification) — either it regressed, or was never fully wired for this case. Either fix the
regression or finish the exclusion properly.

Where this lives: packages/epics/src/common/panel-wrap-layout.tsx (~L221-227) already calls
useCallMembershipRegistry({ excludeRoomIds: [activeRoomId], ... }) where activeRoomId comes
from useGlobalCallDock() (global-call-dock-context.tsx) specifically to exclude the room the
user is currently bound to. So the exclusion mechanism exists — the bug is likely that
activeRoomId isn't staying set (or isn't being read correctly) once the user navigates off the
space page while still on the call. Worth checking global-call-dock-context.tsx's
setActiveRoomId call sites (~L242, 299, 526, 709) against what happens to that state on
route/page changes.

Additional scope for this ticket

• Reproduce: join a call, move to a non-space page (Networks or similar), confirm the navbar
  badge still shows the call you're in as "elsewhere."
• Root-cause why excludeRoomIds/activeRoomId isn't holding across that navigation.
• Fix so a call the user is actively in/PiP-ing is never shown as an active-call-elsewhere
  notification.
• Also fold in the right-panel mount/unmount + elsewhere-call state overlap noted above (feat: notification service redesign — preference-aware, extensible delivery architecture #2470
  D18 connection) if it's touching the same lifecycle — evaluate as part of the same pass
  rather than a second patch, given the shared surface.