perf(desktop): de-block thread aux from first paint, page 500, cache reopens

[wpfleger96]

Opening a long thread (~200-300 replies) in the desktop app was slow and flaky, and reopening the same thread re-ran the entire fetch from scratch. This is PR-2 of the desktop thread-load arc — the fetch-pipeline quick wins.

What was slow

A 300-reply cold open paid four serial relay legs before anything painted:

1. Two content pages — THREAD_PAGE_LIMIT was 200, so 300 replies took two serial get_thread_replies calls.
2. Two aux waves — after both content pages landed, withThreadAux fetched edits/deletions and reactions over all ~301 ids and blocked the resolve on them.

staleTime: 0 meant closing and reopening the panel re-ran the whole pipeline every time.

Changes

• THREAD_PAGE_LIMIT 200 → 500. The bridge clamps a thread page to BRIDGE_THREAD_MAX_LIMIT (500) and the Tauri command caps it with .min(500), so 500 is the largest page the server serves — a ≤500-reply thread now cold-opens its content in a single round trip.
• De-block aux from first paint. loadThreadReplies resolves with content replies as soon as the page loop completes. Structural aux (edits/deletions) and reactions hydrate asynchronously into the same thread-replies cache via a functional setQueryData merge — the exact pattern the channel timeline already ships (backfillAuxForMessages). Accepted tradeoff: an edited reply may briefly render its original text until the merge lands.
• staleTime 0 → 30s on useThreadReplies and useThreadRepliesForRoots, so reopening a recently-loaded thread is a cache hit. While the panel's channel is subscribed, the live WS subscription writes every new content and aux event into the thread-replies key (hooks.ts appendMessage), keeping the warm cache current. The finite bound exists precisely because that self-healing only covers the subscribed channel: edits/deletions/reactions arriving for a thread whose channel is not subscribed never reach the cache, so a 30s staleTime guarantees the next mount refetches and corrects them.

Safety

The async merge uses a functional setQueryData updater keyed on the thread's (channelId, rootId), so it can only touch that thread's cache. It folds aux over whatever content is current rather than a fetch-time snapshot, so a live reply that appends mid-flight is preserved, and aux referencing a message a later refetch dropped simply renders against nothing — content is never resurrected. Both aux fetches stay best-effort: a failure logs and degrades to bare replies.

Tests

Extends useThreadReplies.test.mjs: aux merges into the content cache; both-fetches-fail degrades to bare replies; the merge folds over a live mid-flight append rather than the stale snapshot; and the page-limit/staleTime invariants are pinned.