iris: streaming a transcript event no longer rebuilds the whole screen

Every client (bench_client, transcript_client, desktop-app) refolded and
rebuilt the ~3,200-row widget tree from scratch per SSE event, which is
the streaming-phase cost the P0 benchmark gate would otherwise measure
against a Compose app that updates one row. iris::widget::List gains
replace_back (swap the last row's widget in place, keeping its slot so a
pinned list stays pinned) and clear (the full-rebuild fallback);
transcript_ui::TranscriptScreen::apply diffs the folded row lists and
picks the cheapest update -- unchanged, append, replace-the-last-row, or
(rare regroup) a full rebuild, counted. TextEditCtx::set_with_spans lets a
row's text and span list land together on a streamed update.

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

iris/android-app/src/bench_client.rs

@@ -4,17 +4,21 @@
 //! `transcript-ui`'s real screen with no server -- a frame-time comparison
 //! that measures the renderer rather than the data or the network.
 //!
-//! **Reuses `transcript_client.rs`'s shape** (folded items, a full
-//! `transcript_ui::build_tree` rebuild per event) with the network half
-//! replaced by the checked-in fixture, embedded with `include_str!` --
-//! `app/bench-fixture/assets/transcript.jsonl`, 1,915,760 bytes, generated
-//! by `app/bench-fixture/generate.py` and never a real transcript (that
-//! file's own README). The first 3,200 lines are the opening backlog,
-//! folded once through `client_core::transcript_fold::fold_page` exactly
-//! as a real `/transcript` page would be; the remaining ~400 are the
-//! streaming tail, replayed one at a time through `fold_event` -- the same
-//! fold path a live SSE reply arrives on -- by the "Run benchmark"
-//! control below.
+//! **Reuses `transcript_client.rs`'s shape** (folded items, the same
+//! `TranscriptScreen::apply` incremental update on every event) with the
+//! network half replaced by the checked-in fixture, embedded with
+//! `include_str!` -- `app/bench-fixture/assets/transcript.jsonl`,
+//! 1,915,760 bytes, generated by `app/bench-fixture/generate.py` and never
+//! a real transcript (that file's own README). The first 3,200 lines are
+//! the opening backlog, folded once through
+//! `client_core::transcript_fold::fold_page` exactly as a real
+//! `/transcript` page would be (then a full `transcript_ui::build_tree`,
+//! same as any first load); the remaining ~400 are the streaming tail,
+//! replayed one at a time through `fold_event` -- the same fold path a
+//! live SSE reply arrives on -- by the "Run benchmark" control below.
+//! Streaming through `apply` rather than a full rebuild per event is what
+//! this file exists to measure -- see docs/RUST.md's P0 box for the
+//! before/after report.
 
 use crate::bench_jni::PlatformHandle;
 use android_view::jni::{JavaVM, objects::GlobalRef};
@@ -344,8 +348,15 @@ impl BenchClient {
             let mut sent = 0usize;
             for event in stream_tail.into_iter().take(total) {
                 ctx.update(move |state: &mut BenchClient, rsc| {
+                    let old_items = state.items.clone();
                     state.items = fold_event(&state.items, &event);
-                    state.rebuild_transcript(rsc);
+                    match &state.screen {
+                        // The path P0 asked to measure: update only the
+                        // row(s) that changed instead of rebuilding all
+                        // ~3,200 of them per event.
+                        Some(screen) => screen.apply(rsc, &old_items, &state.items),
+                        None => state.rebuild_transcript(rsc),
+                    }
                 });
                 redraw.request_redraw();
                 sent += 1;