iris: Scroll pans on a finger drag; a vertical drag in a focused field scrolls rather than selects

IRIS_TODO.md's "the composer has no touch-drag scroll". `Scroll::drag`
takes its pan from the same `sense::DragGesture` `List` is driven by --
arbitration, DRAG_SLOP, velocity and pointer capture all stay in sense.rs
and only what a committed pan *means* is decided per caller -- and
`WidgetLike::scrollable()` registers it beside the wheel handler it already
registered, so every scroll area pans on a finger with nothing added at the
call site. No fling: `Scroll` has no per-frame tick to animate one and the
areas it wraps are at most a screenful. `Scroll::amt()` exposes the pan
position.

`attr.rs`'s `on_press` treated an already-focused field as the plain
click_or_drag case, so every Pressing frame extended a selection. It now
applies the same DRAG_SLOP rule its unfocused branch already did: a press
past the slop vertically abandons its pending selection for the rest of the
gesture, so the scroll area around the field wins it. That is Android
EditText's own behaviour and it is what lets a swipe up over the composer
scroll instead of dragging a highlight through what you typed.

Also fixed, found doing it: `ActiveData::mask` stored the mask a widget
*set* rather than the one it was drawn *under*, and `redraw` feeds that
field back in as the inherited mask -- so a targeted redraw of any `Masked`
handed it its own mask and aborted on `set_mask`'s nested-mask assert. A
real abort on the emulator, `assertion failed: self.mask == MaskIdx::NONE`.

And the per-frame orphan guard from 76b1f99 is now a count comparison
(O(active widgets)); the O(primitives) walk only runs to build the failure
message, because running it per frame made a debug build on the emulator too
slow to finish a bench run at all.

Tests: four in scroll.rs (pan past the slop, a tap inside it, a horizontal
drag, the end clamp), `a_finger_drag_over_a_scroll_area_pans_it` in
sense_tests.rs driving the whole registration/dispatch/capture path (fails
with "got 0" without the new registration), and
`redrawing_a_masked_widget_does_not_nest_its_own_mask` in layout_tests.rs
(aborts on the pre-fix code).

The composer itself is deliberately still not `.scrollable()`: `Scroll`
measures against the window rather than its own offered box, so inside the
`MaxSize` capping it at six lines it pans the field out of the bar --
measured, reverted and written down in RUST.md and DECISIONS.md.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>

docs/IRIS_TODO.md

@@ -201,12 +201,19 @@ agent takes them without colliding with that pass's `bench_client.rs`/
   a capped/scrollable height, bottom padding tied to the IME/nav-bar
   inset) -- structurally in place and unit-tested, but its own visual
   correctness cannot be screenshotted until text actually renders.
-- [ ] **The composer has no touch-drag scroll for overflowing text.** The
-  2026-09-06 rebuild caps the field at ~6 lines and wraps it in
-  `.scrollable()` for a wheel/trackpad scroll, but a real finger drag over
-  text that has overflowed the cap does not scroll it -- `Scroll`'s touch
-  handling is a follow-up, the same shape `List`'s own touch-drag pan
-  needed before I3/I5.
+- [~] **The composer has no touch-drag scroll for overflowing text.**
+  **The mechanism is in, the composer is not, 2026-09-06.** `Scroll::drag`
+  takes its pan from the same `sense::DragGesture` `List` uses and
+  `WidgetLike::scrollable()` registers it beside the wheel handler, so
+  every scroll area in the codebase now pans on a finger (no fling -- see
+  IRIS.md). A vertical drag inside a focused field no longer extends a
+  selection, matching Android's `EditText`. But the composer field is
+  **not** wrapped in `.scrollable()` -- the note above was describing
+  intent, not the code -- and wrapping it was tried and reverted: `Scroll`
+  measures against the window rather than its own offered box, so inside
+  the `MaxSize` that caps the field at six lines it pans itself out of the
+  bar entirely (emulator, 474 characters, the bar collapsed to its
+  padding). docs/RUST.md's plan box has the numbers and the next step.
 
 ## From the phone, 2026-09-06, 11:39 (build delivered 02:07, commit 543f6d9)
 
@@ -247,8 +254,17 @@ agent ticks it here with the evidence.
   field the composer may still read as pixels or dp; a stale value from
   before the first `on_insets_changed`. Reproduce with the phone's
   screen size and density on the emulator before guessing.
-- [ ] **"Swiping still gets caught by the grey bar but keeps working
-  after I go past it."** Not closeable from the emulator, annotated
+- [~] **"Swiping still gets caught by the grey bar but keeps working
+  after I go past it."** Improved 2026-09-06 by the focused-field rule
+  below, still needs her phone to close. `attr.rs`'s `on_press` treated an
+  already-focused composer as the plain drag-to-select case, so a swipe
+  starting inside it dragged a highlight through the typed text for the
+  whole gesture; it now abandons that the moment the press passes
+  `DRAG_SLOP` vertically (Android `EditText`'s own rule), which removes one
+  of the two things that made the bar feel like it caught the swipe. The
+  residual `DRAG_SLOP` measured from the boundary crossing, described
+  below, is unchanged. Original note follows.
+  Not closeable from the emulator, annotated
   2026-09-06 after the `DragGesture` merge. `attr.rs`'s `on_press` never
   calls `capture_pointer` and never consumes a `Pressing` frame past
   `DRAG_SLOP` (it just stops watching), so once the finger's *current*