fix(gui): stop detail-pane render storm that froze traffic exploration

[plutack]

Problem

Exploring captures — rapidly clicking rows in the All-traffic view (e.g. capture 5 → 6 → 5 → 5) — froze the GUI, and large bodies eventually crashed the WebKit web process (JS heap exhaustion; confirmed by a user-session WebKitWebProcess SIGABRT coredump with 71 MB core).

Root causes (four, compounding)

1. Poll re-rendered everything: the 2s poll loop installed fresh array identities into state unconditionally, re-rendering the whole tree — including any open detail pane — even when nothing changed.
2. BodyViewer redid heavy work per render: prettyBody (JSON.parse + stringify), regex JSON highlighting, and a full innerHTML swap ran on every render (the dangerouslySetInnerHTML object identity was new each time). For an N-byte body this rebuilt ~4× N of strings/DOM every 2 seconds.
3. Auto-export per click: the ExportSnippet panel embedded in every capture detail fired a snippet conversion on each selection change — each spinning a goja JS VM + httpsnippet eval on the Go side. Rapid clicks piled these up.
4. No click coalescing: every rapid click fetched the full body payload and rendered each response on arrival; bodies were also shipped twice (UTF-8 + base64).

Fixes

• Loaders bail out via functional setState when a row fingerprint is unchanged (webhooks by project/seq, captures by id:status, sessions by id:count:ended) — Preact skips the re-render entirely.
• BodyViewer memoizes all transforms; pretty-print/highlight are skipped above 1 MiB with an explanatory notice; innerHTML prop identity is stable.
• ExportSnippet conversion debounced 250 ms; snippet <pre> uses a memoized HTML object.
• Detail fetches deduplicated per row while in flight; superseded responses dropped (only the last clicked row renders). GetCapture ships base64 only.

Validation (live, Linux/webkit2gtk)

• A 5 MiB JSON body that killed the app outright on the current release now opens fine and stays interactive.
• Idle polling with a detail open: RSS dead-flat between real data changes (previously a 30–60 MB sawtooth every 2 s with a mere 265 KB body).
• Hammer: 12 rapid clicks across 1 MiB-body rows — transient RSS spike, full GC recovery, clicks processed throughout, no crash.

[plutack]

The memoization killed the repeated cost, but opening a multi-MB body still blocked the webview for 0.5–2s per open — the entire body was base64-decoded byte-by-byte, escaped with three regex passes, and materialized as DOM text. Rapid row switching = that cost per distinct row.

7068df8 windows the preview: at most 256 KiB is decoded and rendered up front, with a notice and a Show entire body escalation; Copy/Save/Image decode the full payload on demand; escapeHTML is single-pass; the base64 prefix is cut on a 4-char boundary.

Measured, shipped v0.2.0 vs this branch — same 4.8 MB JSON body, same click program (open big row + rapid row switching)

build	webview CPU	RSS
v0.2.0	~7.1 s	241 MB → 1.2 GB
this PR	~0.5 s	flat (226 MB)

The 1 GB RSS balloon is the sluggishness (GC/swap thrash) and the direct precursor to the WebKit heap-exhaustion crashes.