iris: the composer scrolls on a finger -- a dp cap worth zero, a stale mask slot, a hit box moved twice

Wrapping the composer's field in .scrollable().masked() needed three
layout defects fixed first, each with a headless regression test that was
confirmed to fail without its fix:

- MaxSize/Sized reported a caller's declared dp length unresolved, and
  Span places a child from the abs/rel of what it reported, so dp(168)
  was worth zero: the bar got a slot of nothing the moment its content
  passed six lines and the Scroll inside measured its container at -63px
  (container=-63 content=415.8 amt=478.8 on the emulator). Len::fold_dp,
  used on the way out, plus a debug_assert in draw_inner that a reported
  Size carries no dp -- the rule is about every widget, not those two.
- Masked allocated a fresh mask slot per draw, and draw_inner's
  unchanged-region fast path does not revisit descendants, so they kept
  clipping against a box the bar had moved away from: four live mask
  entries, none of them current, and the field drew nothing.
  ActiveData::own_mask, allocated once and rewritten in place.
- mov updates active.region and accumulates the same delta on the move
  slot, and resolved_region added both, so a panned widget's own hit box
  sat at twice the pan -- the composer's field was untappable after a
  drag. ActiveData::move_applied.

Scroll itself measured the right number by a misleading route; it is
written against painter.px_size() now and still reports its content's
size, since reporting the container makes the answer a function of
itself.

Verified on this checkout's emulator: swipe 540 1200 -> 540 1460 moved
the field's Message box 31,1041..1048,1509 -> 31,1131..1048,1651 with its
height unchanged at 468px.

run-bench.sh polled logcat for a prefix copy_report also logs at startup,
so it printed a report that had never been run.

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

docs/IRIS_TODO.md

@@ -201,19 +201,32 @@ 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 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.
+- [x] **The composer has no touch-drag scroll for overflowing text.**
+  **Done 2026-09-06.** `field.scrollable().masked()` in
+  `transcript-ui/src/composer.rs`: a finger drag inside the bar pans the
+  message, the bar stays capped at six lines, and a vertical drag in the
+  focused field no longer extends a selection (Android `EditText`'s own
+  behaviour). Verified on this checkout's emulator with the
+  `transcript-screen bench force-gles` debug build -- six repetitions of a
+  13-word sentence typed in, then
+  `ui-trace record --do "swipe 540 1200 540 1460 300"`: the field's
+  `Message` box moved `31,1041..1048,1509` -> `31,1131..1048,1651` (the
+  content panned down with the finger) with its **height unchanged at
+  468px** (the bar did not grow), and the two screenshots either side show
+  different text in the same band.
+  Three real defects had to be fixed first, each with a headless
+  regression test in `iris/src/layout_tests.rs` and each confirmed to fail
+  without its fix (docs/RUST.md's plan box has the measurements):
+  a `MaxSize` reporting its cap as an unresolved `dp` (`Len::fold_dp`), a
+  `Masked` allocating a fresh mask slot per draw (`ActiveData::own_mask`),
+  and a panned widget's own hit box moving twice (`move_applied`).
+  `Scroll` itself turned out to measure the right number by a misleading
+  route -- it is written against `painter.px_size()` now, and the claim
+  below that it "measures against the window" was wrong.
+  **Still open, and pre-existing:** the bar's own grey background is not
+  drawn on this build (the `Stack{StackSize::Child(1)}` behind the field),
+  so the message reads as white text over the transcript. Present in the
+  build *before* this change too, so it is not the scroll area's doing.
 
 ## From the phone, 2026-09-06, 11:39 (build delivered 02:07, commit 543f6d9)