fix(desktop): paint thread replies on open without scroll nudge

[wesbillman]

Problem

Opening a thread panel rendered an empty reply list even when the thread had replies (e.g. 24). Scrolling a single pixel made the messages pop into view.

Root cause

The reply list is gated behind useDeferredValue (#1022): the first frame after a thread opens has an empty deferred snapshot while the live list already holds the replies (the head renders; replies stream in a frame later).

useTimelineScrollManager was called with a hardcoded isLoading: false, so its init effect ran scroll-to-bottom on that empty frame and immediately marked itself initialized. When the real replies committed a frame later, they only got the fragile "new latest message" autoscroll path — which loses the timing race. The rows mounted at scrollTop: 0 and stayed unpainted until a manual scroll forced them into view.

The main timeline doesn't have this bug because it passes a real isLoading, and the init effect waits (if (isLoading) return) until content is ready.

Fix

Give the thread panel the same gate the timeline gets for free: treat it as "still loading" while the deferred reply list hasn't committed yet (repliesRenderState === "pending"). Init scroll then fires on the frame the replies actually commit. Genuinely-empty threads ("empty") still init immediately.

   } = useTimelineScrollManager({
     channelId: threadHeadId,
-    isLoading: false,
+    // Wait for deferred replies to commit before scroll-init (else rows mount un-scrolled).
+    isLoading: repliesRenderState === "pending",
     messages: threadMessages,

One line, no new effects, no repaint hacks.

Testing

• pnpm typecheck — clean
• pnpm test — 893/893 pass
• pnpm check (biome + file-size + px-text guards) — pass
• Manual: thread replies render on open without a scroll nudge (verified by @wesbillman)