iris: redrawing one widget cost O(its own primitives squared)

Iris's report was that expanding a tool card holding a long,
horizontally-scrolling edit lags on her phone. The cause is not text
layout: shaping and rasterising a 51,200-glyph block is 20ms, and the
frame that drew it took 1.37 seconds.

A widget redrawn in place frees every primitive it owned and writes
fresh ones. Freeing compacts each layer's draw order with swap_remove,
so ~N primitives are renumbered, and finding the handle to renumber was
a linear scan of everything that widget drew -- O(N^2) in the widget's
own primitive count. A paragraph never notices; one text widget holding
a whole old_string and new_string is every glyph in the card.

The arena now records, per slot, where that slot's handle sits in its
owner's ActiveData::primitives, written at the one place a handle is
taken (Painter::own), and apply_free indexes straight to it.

    50,000 glyphs, redrawn:  before 636ms   after 2.4ms
    per glyph:               before 12.7us  after 0.043us, flat in N

benches/message_list.rs gains scenario (g) for it, reporting per-glyph
because flat is the pass condition and a total hides it. That file had
also stopped running entirely: scenarios (a) and (e) built a LazySpan
with no mask around it, which the span now asserts against, so the
benchmark panicked on its second line. Fixed here too.

Also, on Iris's instruction: the copied report no longer inlines a tail
of the app log. Dev Updater's Runtime tab reads the same ring through
devlog's provider, so it was the same lines twice; the diagnostics pane
still names the provider's authority to read them from.

docs/IRIS.md

@@ -12,7 +12,50 @@ things still stay out.
 An entry gives the date, what changed, why, and a short before/after where
 it helps judge the change without the session that made it. Newest first.
 
-## 2026-09-08 (newest): one `ScrollController`, a `Scrollable` trait, and `Pin`
+## 2026-09-08 (newest): redrawing one widget cost O(its own primitives squared)
+
+Your report -- expanding a tool card with a long horizontally-scrolling
+edit in it lags -- is a framework defect, not a text-layout one, and the
+size of it is not close: **a 51,200-glyph block took 1.37 seconds to
+redraw, of which shaping and rasterising the text was 20ms.** It is 29ms
+now, and the cost is linear in the glyph count rather than quadratic.
+
+What happened. A widget redrawn in place frees every primitive it owned
+and writes fresh ones. Freeing compacts each layer's draw order with
+`swap_remove`, and every primitive that gets swapped into a hole has to be
+told its new position -- so a widget with N primitives generates ~N
+renumberings. Finding the handle to renumber was a **linear scan of
+everything that widget drew**, which made the pass N^2. For a paragraph
+that is nothing. For one text widget holding a whole `old_string` and
+`new_string`, N is every glyph in the card.
+
+The fix is a back-pointer: the primitive arena now records, per slot,
+where that slot's handle sits in its owner's `ActiveData::primitives`
+(`Primitives::handle_index`), written at the one place a handle is taken
+(`Painter::own`). `apply_free` indexes straight to it.
+
+    50,000 glyphs, redrawn:   before 636ms/redraw   after 2.4ms/redraw
+    per glyph:                before 12.7us         after 0.043us (flat in N)
+
+`benches/message_list.rs` grew scenario **(g)** for it, and the number to
+read is per-glyph: flat as N grows is the pass condition, and a total
+hides it. Two things about that file: it also caught the quadratic in
+`--phone`-sized text, and it had stopped running at all -- scenarios (a)
+and (e) built a `LazySpan` with no mask around it, which the span now
+asserts against, so the whole benchmark panicked on its second line.
+Fixed in the same change.
+
+**What this does not fix, and what I would do next.** An open card still
+shapes, rasterises and submits *every* glyph of its input and output, not
+the screenful you can see -- iris does not cull within a widget, and a
+tool card is the one place that bites, because an `Edit`'s `old_string`
+and `new_string` go onto the card whole. The output half is already capped
+(`OUTPUT_LINES`/`OUTPUT_BYTES` in `tool.rs`, 80 lines or 4 KiB behind a
+"Show all"); the *input* half has no cap at all, and that is the
+asymmetry to close. Wrapping the block, which you asked for, changes the
+shape but not this cost: the same glyphs are laid out either way.
+
+## 2026-09-08: one `ScrollController`, a `Scrollable` trait, and `Pin`
 
 Your three points on `docs/SCROLL.md`, in one change. The shape is the one
 you proposed: **a controller both scrolling widgets contain**, rather than