Word wrap (visual-row model) — step 3 of #33 (stacked on #34, #35)

[andrewtheart]

Stacked on #34 and #35. This branch builds on the pixel-offset scroll seam (#34) and horizontal
virtualization (#35), so until those merge this PR's diff also includes their files. Please review #34 → #35
first; I'll rebase this onto master as they land. Opened as a draft.

Step 3 of the editor scroll/render series (#33)

Adds word wrap — the largest piece of the series. The control is currently hardcoded
CanvasWordWrapping.NoWrap; this introduces the visual-row model that makes wrapping work correctly with
scrolling, the caret, selection, click hit-testing and arrow-key navigation.

Why a "visual-row model"

With wrap on, one document line can occupy several visual rows. Vertical scrolling, the caret and
selection therefore have to work in visual-row space, not document-line space. The heart of this PR is that
mapping:

• WrapRowMetrics (pure, WinUI-free) — holds a per-line row count and the cumulative start-row prefix
  sum, maps document line ↔ visual row (binary search), and supports cheap incremental updates so typing
  re-measures only the current line instead of the whole document. The impure per-line measurement (which
  needs a CanvasTextLayout) is injected as a delegate, so all the arithmetic is unit-tested.
• WrapGeometry (pure) — pointer-Y → visual row, and pointer-Y → within-wrapped-line hit-test Y.

Both are covered by WrapRowMetricsTests / WrapGeometryTests (the incremental-update test asserts it
matches a full rebuild).

Integration

• TextLayoutManager — the main text format wraps at the layout width when enabled (line numbers stay
  no-wrap).
• TextRenderer — wrap-metrics lifecycle (EnsureWrapMetrics), visual-row CalculateLinesToRender,
  vertical scrollbar sized in visual rows, wrapped DrawnTextLayout sizing and draw offset, and the
  document ↔ visual-row helpers.
• CursorRenderer — the caret follows its wrapped row (GetCaretPosition().Y) at the line's visual-row top.
• CursorHelper — a click maps Y → visual row → line, then hit-tests the within-line Y.
• SelectionRenderer — selection spans wrapped rows automatically (the wrapped layout's own
  GetCharacterRegions); only the top margin changes for the scrolled-away rows.
• Up/Down arrows move by visual rows in wrap mode (MoveCursorByVisualRows), preserving the target column.
• Public WordWrap on TextControlBox / CoreTextControlBox.

Scope & a request for validation

• Behavior is unchanged when WordWrap is false — every wrap path is gated on IsWordWrapEnabled and
  reduces to the original values, and the normal render path is byte-identical.
• I deliberately excluded the very-long-line wrapped-line virtualization (multi-MB single lines) to keep
  this reviewable — row counting falls back to an estimate above 100k chars so measurement can't blow up, but
  rendering a multi-MB wrapped line is a follow-up. Whitespace-glyph visualization in wrap mode is likewise
  not offset-adjusted yet.
• This is the one PR in the series I can't fully validate headlessly — the pixel-level caret/selection Y
  alignment in wrap mode really wants a run on a real display. The visual-row model is tested and sound; if
  the caret/selection sit a hair off in wrap mode, it'll be a small offset constant in CursorRenderer /
  SelectionRenderer, not a structural issue. I'd value your eyes here and am happy to iterate.

Verification

TextControlBox (library) and the test project build clean (x64).