perf(android): long messages without freezing, and crash hardening

[deymosh]

Summary

A huge markdown message froze the app or caused an ANR. The whole message was one item of the transcript list, so its markdown was parsed synchronously in composition on the main thread, and then laid out and measured in one go, again on every streaming append.

• A long agent or user message is now cut into blocks of about 4,000 characters (markdownBlocks).
  • Cuts fall on blank lines outside code fences.
  • A fence too long for one block is closed and reopened, a long table repeats its header, and an over-long line is cut at a space.
• The cut happens while the entry is decoded, off the main thread.
• Each block is a list item of its own, so only the blocks on screen are composed, parsed and laid out, and streaming re-parses only the last block.
• A plan's outline and the user's bubble are drawn across the blocks as one frame.

Crash hardening (from a scan of the app; no coroutine scope had an exception handler):

• CoreHost.dispatch logs a refused intent (kind only, never fields) instead of crashing.
• A transcript decode failure, a failed view read, a core that fails to open or start, a refused setOnline, a failed keep-alive, a non-derivable npub, a malformed upload URL, a non-JSON signer answer, and an out-of-bounds slash-command highlight are all contained.

Tool results were already capped at 4,000 characters by the agent host, so tool sheets stay bounded.

Test plan

• MarkdownBlocksTest: break points, fences never left open, blank lines inside fences ignored, table header repeated, huge single line, 1 MB in well under a second.
• testDebugUnitTest verifyPaparazziDebug: no existing golden changed; a new transcript_long snapshot was reviewed (the plan frame and bubble are continuous across cuts).
• Device check with a very long reply (maintainer, on the prerelease).

🤖 Generated with Claude Code