iris: a transcript row is a column of markdown blocks, so a streamed delta costs one block

A row was one TextEdit holding the whole message, so every delta
re-shaped every paragraph of a long reply through parley -- the one phase
where iris trails Compose on the phone (p50 18.2ms vs 13.4ms, bench v2).

- client-core/src/markdown_blocks.rs: split a message into its top-level
  blocks with their source, through the same pulldown-cmark the renderer
  parses with so the two cannot disagree about where a block starts, plus
  common_prefix. Appending markdown can rewrite an earlier block (a
  trailing --- turns the paragraph above into a heading), so the fast
  path compares the prefix it keeps rather than assuming it -- with the
  test that says so.
- transcript-ui: a row is a Span of one TextEdit per block;
  RowBlocks::apply_delta replaces the block a delta lands in;
  TranscriptScreen keeps the tail row's blocks, seeded in build_tree as
  well as push_row (a screen opened onto a streaming reply took the
  rebuild path for its first delta otherwise, with nothing to say so).
- A block is the selection unit: Selection is keyed by (RowKey, u32),
  which is reading order at both levels, and the pointer-captured half of
  a drag resolves the block under the finger from its drawn box
  (Selection::locate) instead of from the row's extent.

Pass condition: a_delta_into_a_long_reply_redraws_the_same_widgets_as_a_short_one
drives a real UiRenderState and asserts the draw count for a delta into a
100-paragraph (3,000+ char) reply equals the count for a one-paragraph
one. 30 either way; it read 630 against 30 twice on the way there.

Emulator stream phase, same AVD before and after: p50 61.5 -> 54.5ms,
p90 211.7 -> 113.1ms, p99 342.6 -> 137.4ms, worst 403.6 -> 143.0ms, 202
-> 293 frames in the same 21 seconds. Selection across blocks verified
with a real long-press drag.

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

docs/CLIENT_CORE.md

@@ -191,14 +191,17 @@ does not repeat it again by hand.
 
 ## What is not started at all
 
-- **The markdown *block* model beyond syntax spans** -- `highlight/markdown.rs`
-  colours a `.md` file or fence for the highlighter, but does not build the
-  block tree (headings, lists, tables, fences as distinct nodes) that a
-  renderer walks to lay out prose versus code versus a table.
-  `CodeFence.kt`'s use of `org.intellij.markdown` for that full CommonMark
-  AST is Compose rendering plumbing, not something to port as-is; a Rust
-  UI layer will want its own block parser or a crate for it, decided
-  alongside the framework choice in RUST.md.
+- **A full markdown AST.** `markdown_blocks` (2026-09-06) splits a message
+  into its *top-level* blocks -- heading, paragraph, fence, list, table,
+  quote -- with each block's own source, which is what a renderer needs to
+  lay out prose versus code and what lets a streamed delta re-lay out one
+  block instead of the message (docs/RUST.md's Task B). What it
+  deliberately does **not** build is the tree below that: nested list
+  items, table cells, inline spans. Inline styling is still the renderer's
+  own job per block (`iris/transcript-ui/src/markdown.rs`), and nothing
+  has needed the rest yet. `CodeFence.kt`'s use of `org.intellij.markdown`
+  for a full CommonMark AST is Compose rendering plumbing, not something
+  to port as-is.
 - **`TranscriptUnits.kt`** (see above) -- deliberately out of scope, since
   it flattens a row into bounded units for a *specific* lazy-list
   framework's composition cost, which is a fact about that framework
@@ -209,5 +212,5 @@ does not repeat it again by hand.
 `./run-tests.sh` from the repo root now runs `event-model`, `client-core`
 and `server` in that order (each `cargo test`, forwarding arguments the
 same way it always has). From `client-core/` directly: `cargo test`
-(109 tests), `cargo clippy --all-targets`, `cargo fmt` -- all clean as of
+(119 tests), `cargo clippy --all-targets`, `cargo fmt` -- all clean as of
 this writing (2026-09-06).