Draw the line numbers beside the file, not inside it

The stretch is rendered on the box around the list, so everything in that
box bent with it -- the numbers included. `Modifier.overscroll` wraps the
effect's single node, so one effect cannot be rendered in two places and
the numbers cannot be excluded while they live in the rows. They had to
leave.

They now sit beside the scrolling box: the rows leave a spacer where the
numbers go and a `SubcomposeLayout` draws them there. That is the one
arrangement that keeps them level with their lines, which is the thing a
numbered listing may never get wrong. Which numbers exist *and* where each
one goes both come from the list's own `layoutInfo`, read in the measure
block -- and subcomposition happens during measurement, so it composes from
the answer the list has just produced rather than from one it read a frame
ago. A column translated by the scroll position could not do that: the
translation would be a layout read and current while the set of numbers was
a composition behind it, and during a fling the numbers would slide against
their lines.

Checked by sampling the screen at about 1kHz through a fling: 23,520 row
observations over 552 frames, every one with its number at exactly its own
top, no drift at any point. Also that the gutter holds its x while the text
scrolls sideways, and that a short file and an empty one still draw.

A consequence worth having: the numbers are no longer inside the
`SelectionContainer`, so selecting part of a file and copying gives the code
rather than the code with a number in front of every line. That follows from
where they are now rather than from anything asked for, and a copy was not
exercised.

The stretch itself still cannot be seen from this VM, so whether the numbers
now stay flat while the text bends is the thing to look at on the phone.

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

EXPLORER.md

@@ -190,6 +190,23 @@ end is. It cannot be seen from this VM: the emulator's screenshots come
 back with no stretch in them at all, for any scrollable, so this one is
 checked on the phone.
 
+**The numbers sit outside that box**, so they neither travel with the text
+nor bend with it. The rows leave a spacer where the numbers go and a
+`SubcomposeLayout` beside the list draws them. That is the one arrangement
+that keeps them level: which numbers exist *and* where each goes both come
+from the list's own `layoutInfo`, read in the measure block, and
+subcomposition happens during measurement -- so it composes from the answer
+the list has just produced rather than from one it read a frame ago. A
+column translated by the scroll position could not, since the translation
+would be current while the set of numbers was a composition behind, and
+during a fling the numbers would slide against their lines. Checked at
+about 1kHz through a fling: 23,520 row observations over 552 frames, every
+one of them with its number at exactly its own top.
+
+A consequence worth having: the numbers are no longer inside the
+`SelectionContainer`, so selecting part of a file and copying it gives the
+code rather than the code with a number in front of every line.
+
 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