iris: the arenas upload deltas, and stop being 11x bigger than the tree

Changing any primitive re-uploaded every primitive. Measured over the
bench fixture by the new arena_churn rig: 758 MB across a fling and
1.2 GB across 401 streamed deltas, p50 3.0 MB per streamed frame.

Three separate things were wrong, and only the first is what it looked
like from the outside.

ArrBuf reallocated on every length change. A fresh Buffer's contents are
undefined, so adding one glyph -- which a streamed reply does constantly
-- forced a full rewrite, and no partial upload could have been correct
in the first place. It has a capacity now, growing geometrically and
never shrinking, and update() answers whether the Buffer identity moved
so a caller can rebuild its bind group and force the whole range dirty.
That alone took the glyph array from 95% re-uploaded to 3%, and stopped
primitive_group being rebuilt on every frame the arena changed.

A redraw freed its primitives and pushed new ones. Freed slots are not
reusable until the end of the frame -- a layer's draw order still names
them -- and Painter::draw_twice is how a container learns a child's
size, so with containers nested the arena's high-water was the transient
push count rather than the live one: 17 million pushes across 401
deltas, 127,443 slots for 11,569 live primitives, growing linearly with
the transcript. A redraw now gets its old handles back as a recycle pool
(Painter::take_recycled, Primitives::recycle) and writes into the slots
it already holds; the pool is consumed in order and whatever the draw
does not claim is freed when it ends. The arena is exactly the live
count now. The CPU frame improved with it, from p50 2.20ms to 1.39ms on
the stream run, because the freeing and the draw-order renumbering went
away.

Nothing tracked which entries changed. util::Dirty is a bitset per
uploaded array, coalesced into ranges at a 1 KiB gap. Marking is O(1)
and allocation-free; reading it back is one word per 64 entries. Both
alternatives were measured and rejected: a min..max span is nearly the
whole buffer, since a frame's changes land in 5-20 scattered runs, and a
Vec of indices would mean an allocation and a sort per frame at several
thousand marks. It replaces Primitives::updated -- one bool that covered
the instances and the per-primitive data together, so rewriting a rect's
region re-uploaded every glyph -- and TrackedArena::changed.

The trap only the rig could catch: writing an entry is not changing it.
Recycling rewrote every glyph of every moved row with identical bytes,
marking 73% of the glyph array against 0.6% genuinely changed, because
what moves is the instance's region and not the glyph. PrimitiveVec::set
and Primitives::set_instance compare before marking.

Every array now uploads within a hair of its floor: fling instances 3.4%
against 3.3%, fling glyphs 0.9% against 0.8%, stream glyphs 0.6% against
0.6%. Stream instances are at 72.7%, which *is* the floor and is a
layout question rather than an upload one -- the list is pinned to the
newest end, so a growing reply moves every row, and that should be one
move_offsets write rather than a redraw. Noted in RUST.md as the next
thing.

Also: draw_inner's four old_* parameters become one Retained struct, so
the recycle pool is a field rather than an eleventh positional argument
next to three others of the same shape; and free_primitive is the one
place a slot and its draw-order position are retired together.

The rigs move to scripts/rigs/ui-profile, a crate of their own so a
rig's dependencies stay out of the app's -- arena_churn needs bytemuck,
which nothing in ai-app does. arena_churn prints floor, uploaded and
whole side by side per array, because any two of those alone are
misleading and the 122x over-marking above was invisible until all three
were on screen together.

docs/RUST.md

@@ -472,7 +472,7 @@ the view keeps **one**, anchored by whichever of a touch or a frame
 arrives first, so a fling is advanced on the clock its velocity was
 measured on.
 
-What the CPU side is *not*: `app-rust/tests/frame_profile.rs` (AGENTS.md's
+What the CPU side is *not*: `scripts/rigs/ui-profile`'s `frame_profile.rs` (AGENTS.md's
 rig list) puts iris's own per-frame work during a warm fling at p99
 0.26ms, with only one frame in six laying anything out at all. The
 multi-millisecond spikes are first-pass only.
@@ -635,6 +635,52 @@ the reply into blocks was still right -- it is what makes the fixture
 representative, and it halved the CPU half -- but it was never going to
 move this, and it slightly increases the primitive count.
 
+### The arenas upload deltas, and stopped being 11x too big (2026-09-09)
+
+Done, and measured by `scripts/rigs/ui-profile`'s `arena_churn` -- see
+AGENTS.md's entry for the rig and the numbers. The arithmetic above was
+right about the symptom and wrong about the cause being the upload
+strategy alone. Three things, in the order they had to be fixed:
+
+1. **`ArrBuf` reallocated on every length change**, and a fresh buffer's
+   contents are undefined, so a partial upload could not have been
+   correct in the first place. It has a capacity now: geometric growth,
+   never shrinking, and `update` says whether the `Buffer` identity moved
+   so a caller can rebuild its bind group and force the whole range
+   dirty. This alone took the glyph array from 95% re-uploaded to 3%.
+2. **A redraw freed its primitives and pushed new ones.** Freed slots are
+   not reusable until the end of the frame (a layer's draw order still
+   names them), and `Painter::draw_twice` -- how a container learns a
+   child's size, and containers nest -- meant the arena's high-water was
+   the *transient* push count: 17 million pushes across 401 deltas, and
+   127,443 slots for 11,569 live primitives, growing linearly with the
+   transcript. A redraw now gets its old handles back as a recycle pool
+   (`Painter::take_recycled`, `Primitives::recycle`) and writes into the
+   slots it already holds. The arena is exactly the live count now, and
+   the CPU frame fell from p50 2.20ms to 1.39ms as a side effect, since
+   the freeing and draw-order renumbering went away.
+3. **Nothing tracked which entries changed.** `util::Dirty` is a bitset
+   per uploaded array, coalesced into ranges at a 1 KiB gap. Marking is
+   O(1), and the read-back is one word per 64 entries. A `min..max` span
+   was rejected on measurement (a frame's changes land in 5-20 scattered
+   runs, so a span is nearly the whole buffer) and so was a `Vec` of
+   indices (thousands of marks per frame would mean an allocation and a
+   sort).
+
+The trap that only the rig could have caught: writing an entry is not the
+same as changing it. Recycling rewrote every glyph of every moved row with
+identical bytes, marking 73% of the glyph array against 0.6% genuinely
+changed. `PrimitiveVec::set` and `Primitives::set_instance` compare before
+marking, and `arena_churn` prints both numbers so the gap cannot reopen
+unnoticed.
+
+**What is left, and it is a layout question rather than an upload one.**
+Stream instances upload 72.7%, which *is* the floor: the list is pinned to
+the newest end, so a growing reply moves every row, and a row's instances
+carry an absolute region. Moving a subtree is supposed to be one
+`move_offsets` write (LAYOUT.md section 2); something on this path is
+redrawing instead.
+
 ### The Android release profile is `opt-level = 3`, not `"s"` (2026-09-09)
 
 The table above was measured in bytes only. `"s"` costs the loop