Wrapped-line virtualization — completes #33's word-wrap step (stacked on #34/#35/#37)

[andrewtheart]

Stacked on #34, #35, #37. Builds on the scroll seam (#34), horizontal virtualization (#35) and word
wrap (#37), so until they merge this PR's diff also includes their files. Please review that chain first —
especially the word-wrap foundation #37 — I'll rebase onto master as it lands. Draft for that reason.

Completes #33's word-wrap step: wrapped-line virtualization

The word-wrap PR (#37) deliberately left one gap: a single line so long it wraps to more rows than fit on
screen. #37 falls back to estimating such a line's row count (so the metrics don't blow up), but it still
lays the whole line out to render it — a multi-megabyte minified/JSONL line in wrap mode would build a giant
CanvasTextLayout and freeze. This PR virtualizes the rendering of that line.

Approach

When the only visible line is a very-long wrapped line (≥ 100k chars), the renderer materializes just the
visible row slice of it — starting at the scrolled-to row, on the same estimated char-per-row grid the
metrics already use — instead of the full line. The caret, click hit-testing and arrow navigation map onto
that grid (GetRenderedCharacterIndexForDocumentCharacter / …FromRenderedIndex gain a virtualized branch,
MoveCursorByVisualRows navigates the grid arithmetically instead of laying out the line, and the caret/
hit-test treat the line as pinned to the viewport top).

Changes

• Core/Renderer/TextRenderer.cs — virtualization state + ShouldVirtualizeWrappedLine /
  BuildVirtualizedWrappedLineRenderData / EstimateWrapped*; virtualized branches in Draw,
  UpdateCurrentLineTextLayout, the index mappers, MoveCursorByVisualRows and the hit-test. Row counting
  now shares the same estimate helpers so the metrics and the render agree.
• Core/Renderer/SelectionRenderer.cs — guards selection (see limitation).

Known limitations (documented, niche)

• Selection and search-highlighting inside a virtualized line are skipped — the layout is only a row
  slice, so document-space indices don't map onto it. Selecting/searching within a single multi-MB line is
  the only case affected; everything else is unchanged. Skipped rather than drawn wrong (and it avoids
  overrunning GetCharacterRegions). Happy to follow up if you want full support.
• The row grid is an estimate (monospace assumption), so scroll-thumb proportions on such a line are
  approximate — same trade-off Word wrap (visual-row model) — step 3 of #33 (stacked on #34, #35) #37 already makes for row counting.

Behavior & verification

No effect unless word wrap is on and a visible line is ≥ 100k chars. Library + test project build clean
(x64). This is the most experimental piece of the series and, like #37, wants a run on a real display — happy
to iterate.