Move LazySpan rows through one retained offset

docs/SCROLL.md

@@ -272,18 +272,21 @@ cannot pan; there is a `debug_assert` in `drag` naming that.
 
 ## Measurements worth not re-taking
 
-- A settled scroll tick of a `LazySpan` with 31 rows on screen:
-  **1 real draw and 31 move-slot writes**, no primitive rewrites and no
-  text reshaped. An idle frame is `(0, 0, 0, 0)` — `draw_inner` does not
-  even enter the widget. This is the number any "store the edges and only
-  recompute what changed" optimisation would have to beat, and it is why
-  the walk was left alone.
+- A settled scroll tick of a `LazySpan`, for 20, 200 or 2,000 total rows:
+  **1 real draw and 1 child-coordinate move-slot write**, no primitive
+  rewrites and no text reshaped. The visible-row walk remains: it is what
+  admits and retires rows at the viewport boundary, and a newly admitted row
+  has real initial-placement work of its own. An idle frame is `(0, 0, 0,
+  0)` — `draw_inner` does not even enter the widget.
 - A fully hinted `Span` draws each child once. Unknown fixed children draw
   provisionally and move; region-dependent children redraw if their final
   box has a different size.
-- The one design that would collapse those 31 moves into a single delta
-  write is moving the content as a unit, which needs a content length —
-  which a lazy layout cannot supply.
+- Moving the currently retained run as a unit does **not** require the lazy
+  span's unknowable total content length. Its anchor supplies the relation
+  between stable local row boxes and their desired screen boxes; one retained
+  child-coordinate slot carries that translation. The offset is occasionally
+  rebased after 65,536 pixels to preserve `f32` precision, a rare O(visible)
+  move-slot pass rather than steady-state work.
 
 ## Tests that pin the behaviour