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

[MikelCalvo]

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 fix(desktop): disable backdrop-blur on Linux for perf #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.

• Slow UI performance on linux #3328 covers general Linux UI performance, but this was reproduced with a native build and isolated to the number of mounted thread replies.
• fix(thread): stop mid-scroll content jump in live threads #1397 removed content-visibility from thread replies because it caused scroll jumps.
• Retain a stable message window in channel timelines #1698 virtualizes the main channel timeline, not the thread panel.
• perf(desktop): isolate typing/working store churn from ChannelPane #5050 and perf(desktop): memo timeline row wrappers under live reformats #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.