useUserPresence registered 3 client listeners (Presence / CurrentlyActive / LastPresenceTs) PER hook instance. On a large room that meant 100-250 global listeners, every presence event fanning out across all of them, with add/remove churn on every fast scroll. Replace with a module-level PresenceStore singleton that registers exactly 3 listeners total (lazily, on first subscriber) and fans out to per-user subscribers itself. The hook keeps the same public API (useState + a subscribe effect); consumers are unchanged. Cache + subscriber sets stay bounded to currently-mounted users; the mx-swap branch re-homes listeners on re-login. Reviewed by two passes (SDK mutate-before-emit ordering and handler signatures independently verified). Includes their recommended hardening: the unsubscribe is made idempotent via a set-identity check so a double-invoke / re-subscribe can't evict a newer subscriber. Note: a User object that appears silently with no presence event no longer re-seeds (deps are [mx, userId] not [mx, user]); the common presence-EDU case is handled (and better than before). Reviewers rated this narrow case Low. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>