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/DECISIONS.md

@@ -5,6 +5,29 @@ they can be judged and reversed later. Detail lives in RUST.md (and IRIS.md
 for iris API changes); this file is only the summary. Newest first. Items
 marked **DEFERRED** are ones the agent chose not to decide alone.
 
+## 2026-09-06 (stale-primitives and touch-scroll pass)
+
+- **A vertical drag inside a focused composer now scrolls rather than
+  selects.** Android's own `EditText` does this -- a vertical drag scrolls
+  the field, and only a long press starts a selection -- so the platform
+  decided it. What it costs: you can no longer drag straight down inside
+  the composer to select several lines of what you typed; use a long press
+  and then drag, or drag sideways. Say if that trade is wrong for you.
+- **`Scroll` gets a finger pan but no fling.** `List` flings; a scroll area
+  does not, because it has no per-frame tick to animate one and the areas
+  it wraps are at most a screenful (Android does not fling a six-line text
+  box either). Easy to add later if a scroll area ever wraps something long.
+- **The composer still does not scroll its overflowed text**, though the
+  mechanism it needs is now in place. Wrapping the field in `.scrollable()`
+  was tried and reverted the same day: `Scroll` measures its content and
+  container against the *window*, so inside the `MaxSize` that caps the
+  composer at six lines the two are in different spaces and the field pans
+  itself entirely out of the bar (measured on the emulator with 474
+  characters in it -- the bar collapsed to its padding). Fixing that means
+  `Scroll` measuring against its own offered box, which is a change to a
+  widget the transcript and the bench shell both use, so it is its own
+  piece of work rather than a rider on this one.
+
 ## 2026-09-06 (defect pass)
 
 - **The keyboard-open diagnostics overlay is gone; the capture only