perf(desktop): prefetch the channel window on sidebar hover intent

[Maxwellimus]

Based on perf/switch-tracing — retarget to main after it merges. (Shares the message-window queryFn hunk with the tracing instrumentation.)

A deliberate hover on a sidebar channel row (100ms dwell — pointer scrubbing never fires) warms that channel's message window, so the subsequent click paints from cache instead of paying the relay fetch on the switch path. Live traces measured that fetch at 180–310ms per cold channel entry on a real community — this moves it into the hover dwell, ahead of the click.

The window's query options move into a shared factory so the prefetched entry is byte-identical to what the mounted query reads; the prefetch respects the window's staleTime (hovering a fresh channel never refetches) and dedupes with in-flight fetches. Forum channels are excluded, matching the window query's own gating.

The post-subscribe window refresh cancels an in-flight prefetch rather than deduping onto it: a prefetch reaches the relay before the live subscription exists, so its snapshot can miss events that landed in between. A cold mount fetch is still parked on the persisted-head gate, carries no such gap, and must keep deduping (#6455's one-fetch contract) — channelWindowPrefetches.ts is the marker that tells the two apart.

The mock bridge gains a head-fetch probe (cursorless window reads) and a regression spec asserts both directions: dwell fetches exactly once before any click; scrubbing across rows fetches nothing.

---

Recreates #6459. It was approved and squash-merged into its stacked base perf/switch-tracing, but a force-push of that base (carrying the review-requested P1 fixes for #6455) raced the merge and overwrote the squash commit — so the merged content never survived on the base branch. Same content, same base; still stacked on #6455 and should merge after it.