Record why the viewer's rows all share one width

EXPLORER.md's decision 8 said "one shared horizontalScroll state", which is
what was built and is not sufficient on its own -- the reason is worth
having beside the decision rather than only in the code that now works.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

EXPLORER.md

@@ -164,6 +164,23 @@ draw a screenful. Lines are drawn with `softWrap = false` inside one
 shared `horizontalScroll` state, so the whole file scrolls sideways as a
 block and a line never wraps.
 
+**Sharing that state is not enough on its own, and this is where it was
+wrong.** `horizontalScroll` is a node per row, and each one coerces the
+shared offset into *its own* range -- content width less viewport -- so
+with rows at their natural widths a short line's range is zero and it does
+not move at all while the long line beside it does. Each row also writes
+`maxValue` as it measures, so how far the file could be dragged was decided
+by whichever row measured last, and changed as the list scrolled. Both go
+away once **every row is given the same width**: the longest line in
+columns times one character's advance, which is arithmetic rather than
+twenty thousand measurements because the face is monospace. A tab counts as
+eight columns and deliberately upwards -- over-estimating leaves a little
+empty space past the longest line, under-estimating puts the end of that
+line out of reach -- and the width is capped well under what `Constraints`
+can carry, so a minified file is a scroll that stops early rather than a
+crash. Reported by Iris on 2026-09-04 as "it seems to affect different rows
+differently", which is precisely what a per-row range looks like.
+
 Line numbers are a gutter in each row, right-aligned, with the gutter
 width taken from the digit count of the line count in the same monospace
 style -- so a 9-line file and a 12,000-line file each get exactly the