[Desktop] Large thread panels mount every reply, causing high CPU and memory use

**Describe the bug**

Opening a large thread in Buzz Desktop can make the UI severely laggy. In the affected thread, `WebKitWebProcess` used more than one CPU core and several gigabytes of resident memory.

The thread loader fetches replies in pages of 200 until the subtree is exhausted, while `MessageThreadPanel` mounts the complete visible reply list through `threadReplyRenderItems.map(...)`.

**Steps to reproduce**

1. Open a channel thread with a large reply history, especially one containing long Markdown or agent output.
2. Expand nested branches if needed.
3. Scroll through the thread panel.
4. Observe delayed scrolling and input, high `WebKitWebProcess` CPU usage, and increasing renderer memory.

**Expected behavior**

Opening and reading a large thread should not cause CPU and memory use to grow with every mounted reply. Deep links, unread state, nested branches, live replies, copying, and scroll anchoring should continue to work.

**Measured result**

Test environment:

- Buzz Desktop 0.5.8, native Arch Linux build
- Arch Linux, KDE Plasma 6.7.3
- WebKitGTK 2.52.5
- NVIDIA RTX 3070
- `WEBKIT_DMABUF_RENDERER_FORCE_SHM=1`
- Linux backdrop filters disabled using the change from #3533

With the same thread:

- Unbounded panel: approximately 139-174% `WebKitWebProcess` CPU and 2.5-3.35 GB RSS shortly after opening. A longer session reached approximately 4.6-5 GB RSS.
- Diagnostic build mounting only the newest 60 replies: approximately 48-71% CPU and 0.97-1.04 GB RSS.

The 60-reply change was only a diagnostic test, not a proposed implementation. The result suggests that the number of mounted reply rows is the main bottleneck after the Linux rendering fixes.

**Source evidence**

- `desktop/src/features/messages/useThreadReplies.ts` fetches 200 replies per page and continues until the thread is exhausted, with a 500-page safety limit.
- `desktop/src/features/messages/lib/threadPanel.ts` flattens expanded reply subtrees into one visible list.
- `desktop/src/features/messages/ui/MessageThreadPanel.tsx` mounts that list using `threadReplyRenderItems.map(...)`.

**Related work**

I could not find an open issue or PR that limits or virtualizes the replies mounted by `MessageThreadPanel`.

- #3328 covers general Linux UI performance, but this was reproduced with a native build and isolated to the number of mounted thread replies.
- #1397 removed `content-visibility` from thread replies because it caused scroll jumps.
- #1698 virtualizes the main channel timeline, not the thread panel.
- #5050 and #5071 reduce rerenders but do not bound the mounted thread reply list.

**Version and platform**

- Buzz version: 0.5.8
- OS: Arch Linux, KDE Plasma 6.7.3

**Additional context**

I can provide additional profiling data or test a proposed fix against the affected thread if useful.

Start by reading desktop/src/features/messages/useThreadReplies.ts and desktop/src/features/messages/lib/threadPanel.ts to understand reply loading and flattening, then inspect threadReplyRenderItems.map(...) in desktop/src/features/messages/ui/MessageThreadPanel.tsx. Reproduce with a large thread and compare CPU and memory while scrolling. Done means large threads no longer mount unbounded replies while deep links, unread state, nested branches, live replies, copying, and scroll anchoring continue to work.

Written by the indexing model from the issue text.