perf(forge): virtualize the issue/PR comment thread, and load it by scrolling

A thread of three hundred comments was three hundred mounted Markdown
renderers. `MessageResponse` memoizes, so the cost was never the
re-renders — it was parsing and building three hundred subtrees to show
two of them. The list now windows through virtua, bound to the pane's own
scrollport rather than a nested one, so the wheel still carries down the
whole panel.

That costs a `startMargin`: virtua only measures its own offset when its
parent IS the scroller, and here the item's description sits above it at
whatever height the author's Markdown came to. It is measured from the
list's own top against the scrollport, which is free of feedback in both
directions — the list is below everything the measurement covers, so its
height cannot move its top, and the rect reads cancel against `scrollTop`.

Reading to the end now asks for the rest, which is the other half of
"hundreds of comments": windowing them costs nothing if getting to them
still takes fifteen clicks. The in-flight flag is not the same guard as
`loading` — virtua hands over whichever callback its effect last
committed, so the frame after a fetch starts still reaches the one that
closed over "nothing in flight", and scroll events arrive every frame. A
failure stops it dead, so a broken network cannot retry the same page
forever; recovery stays on the strip's "Try again".

"Load more" stays. It covers what the scroll cannot: GitLab filters its
system events after paginating, so a page with nothing on it is a page
nobody can scroll to the end of, and the discussion is still behind it.

Verified in a real engine (jsdom lays nothing out, so none of this is
observable in the unit tests): the measured margin matches the list's own
top, the window tracks the scroll with no blank strip at either edge, only
a handful of the loaded comments are ever mounted, the gutter avatar still
pins inside virtua's absolutely positioned rows, and reaching the end
pulls the next page in.