/* ── Long-conversation rendering optimizations ─────────────────────────
 *
 * Three CSS optimizations have been tried on ``.message-row`` and all
 * three were ULTIMATELY REMOVED because each caused a real, repeatable
 * scroll-geometry bug:
 *
 *   1. ``contain: layout`` — when a child ``<details
 *      class="thinking-block">`` collapsed (either via
 *      ``markThinkingDone`` mid-stream OR via a user click), the row's
 *      contribution to ``#hy-chat``'s ``scrollHeight`` got stranded at
 *      the pre-collapse value on Chromium. The user would scroll up
 *      to read history, drag the scrollbar back to the bottom, and
 *      the thumb would hit the end of the track while the chat
 *      stopped many screens above the latest message; the wheel did
 *      nothing because they really were at ``scrollHeight -
 *      clientHeight``. Manually toggling the collapsed Thinking block
 *      open forced a relayout that fixed it — the diagnostic
 *      fingerprint.
 *
 *   2. ``contain: paint`` — the same symptom recurred under a
 *      narrower trigger: assistant turns containing wide elements
 *      (most commonly markdown tables, also ``katex-display`` blocks,
 *      and fenced code with long lines). ``paint`` containment makes
 *      the row a stacking context AND clips overflow at the contain
 *      box. Combined with the post-stream lazy-render passes
 *      (``hljs.highlightElement``, KaTeX re-render of the streaming
 *      tail, table column-width pass), the row's reported size in
 *      ``#hy-chat``'s scroll metrics drifted away from its real
 *      rendered size by hundreds-to-thousands of pixels. Toggling
 *      Thinking no longer fixed this case because the stranded value
 *      was on the post-table row, not the row containing Thinking.
 *
 *   3. ``content-visibility: auto`` — skipping render for off-screen
 *      rows. Row heights vary wildly (a "你好" reply is ~40px, a
 *      math derivation or table-heavy answer is 3000–5000px). With
 *      ``contain-intrinsic-size: auto 240px`` as the placeholder,
 *      scrolling up by a tiny amount caused off-screen rows to expand
 *      from 240px to their real size, growing ``scrollHeight`` by
 *      thousands of pixels in a single frame. Browser scroll
 *      anchoring did not reliably compensate, so the view jumped far
 *      up the conversation and felt broken.
 *
 * If we ever need any of these optimizations back, gate them behind a
 * row-count threshold (only apply to rows older than the last N) and,
 * for option 3, measure each row's real height before swapping it out
 * so ``contain-intrinsic-size`` is per-row rather than a single
 * global guess. For options 1 & 2, also wire a ``ResizeObserver`` on
 * each row that re-dispatches ``hy-chat:updated`` whenever the row's
 * height changes (the scroll-lock in ``static/app.js`` uses that
 * event to re-evaluate / re-pin). */