fix(room): IDB load no longer waits for WS connection

loadMore(null) fires immediately — cached messages render instantly.
WS connect runs in parallel; subscribeRoom and reaction batch-fetch
use WS-first request() which falls back to HTTP transparently.

src/contexts/room-context.tsx

@@ -241,17 +241,16 @@ export function RoomProvider({
     if (!activeRoomId || !client) return;
 
     const setup = async () => {
-      // Ensure WS is open before subscribing. connect() is idempotent — if already
-      // connecting/open, it returns immediately. While connecting, messages load from
-      // IDB (instant) and reactions batch-fetch via WS-first request().
-      await client.connect();
-      // Guard: room may have changed while we were waiting for connect.
-      if (activeRoomIdRef.current !== activeRoomId) return;
-      // subscribeRoom is WS-first with HTTP fallback; failure is non-fatal.
-      client.subscribeRoom(activeRoomId).catch(() => {});
-      // loadMore checks IDB first (no WS needed), then batch-fetches reactions
-      // via WS with HTTP fallback. Safe to call without awaiting.
+      // IDB load does NOT need WS — show cached messages immediately.
+      // loadMore checks IDB first, then falls back to API (WS-first + HTTP).
       loadMore(null);
+
+      // Connect WS in parallel for real-time push + reactions batch-fetch.
+      // connect() is idempotent — no-op if already connecting/open.
+      // subscribeRoom uses WS-first request() with HTTP fallback.
+      await client.connect();
+      if (activeRoomIdRef.current !== activeRoomId) return;
+      client.subscribeRoom(activeRoomId).catch(() => {});
     };
     setup().catch(() => {});