Draw a peer message a block at a time, and parse it off the drawing thread

A message from another agent was the one markdown in the app still rendered
whole: one parse and one display list for the entire thing. Every settled
reply has been cut into blocks since the transcript was made lazy, and
`warm` has been making those parses ahead on a background thread -- but it
filtered for assistant replies alone, so the longest message a transcript
holds was also the only one parsed on the thread that draws.

Measured on the emulator against a 43KB peer message, opening it: 177ms in
`markdown parsed while composing`, against none afterwards and 156 blocks
already ready. What is left is the card being a single list item, so all 156
blocks are still measured, placed and recorded at once -- 118ms of placement
in that same frame.

The `when` in `warm` is now the rule rather than a filter: every row that
draws markdown belongs in it.

Blocks are spaced by the transcript's own BLOCK_SPACING rather than the
renderer's internal padding, which moves a heading about 6px (2.3dp) closer
to the paragraph above it. The message's total height is unchanged, and it
now matches every reply in the transcript.

While here: FrameStats was remembered per session screen and DebugStats is a
global emptied only by the copy button, so the two halves of a render report
covered different stretches of time -- and `drawAccounting` divides one by
the other. A report copied after visiting two sessions claimed 36.8 seconds
of placement inside a 13.5 second window, and clamped "everything else" to
0.00ms (0%), which reads as a screen whose entire cost is this app's code.
One FrameStats for the app, so both halves mean "since this was last copied".

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

app/androidApp/src/main/kotlin/com/example/aiapp/PeerMessage.kt

@@ -27,6 +27,10 @@ import androidx.compose.ui.unit.dp
  * Drawn as its own kind rather than as the reader's own bubble. They did not say this, and a
  * transcript that puts it in their voice is making a claim about who asked for the work that
  * follows -- which is exactly the question a peer message is usually the answer to.
+ *
+ * Opened, it is drawn a block at a time ([BlockedMarkdown]) for the reason every reply already is:
+ * these are the longest messages a transcript holds, and one of them as a single render is one
+ * parse and one display list proportional to the whole of it. See [markdownBlocks].
  */
 @Composable
 fun PeerMessageRow(
@@ -52,7 +56,7 @@ fun PeerMessageRow(
                     )
                 }
             }
-            if (expanded) MarkdownText(item.text, replies, Modifier.padding(top = 6.dp))
+            if (expanded) BlockedMarkdown(item.text, replies, Modifier.padding(top = 6.dp))
         }
     }
 }