Add new Markdown layout engine and use paged scrolling for long chat transcripts

[lucasnewman]

This change is large but it resolves most of the interface issues with chat transcript scrolling performance and scroll following in my fairly extensive testing.

1. Switch from using MarkdownUI to our own Markdown implementation on top of cmark-GFM so we can exactly match layout size estimates with the actual rendered content
2. Use paged scrolling behavior for the chat transcript. The latest messages are always fully rendered and we page in earlier history when reaching the top of the scroll view. This keeps the set of rendered messages bounded during active decode so we don't compete with CPU usage for the decoding.
3. Consolidate scrolling following for streaming decoding and respect manually scrolling events to unpin the following behavior, so scrolling always stays smooth.
4. Move the live decode statistics into the composer to avoid the jumping behavior from scroll following during streaming decoding.
5. Add UI tests for scrolling behavior to ensure we don't regress scroll following.

Example video showing that Nativ never exceeds ~40% cpu during decoding and scroll sizing adjustments only occur when paging in new content, similar to how Codex handles very long transcripts.

[lucasnewman]

This test was obsoleted by an unrelated change so I deleted it since it's failing.

[lucasnewman]

I'm not in love with the decode speed indicator view, but it's not so different from today so I figured we could handle an improved design as a follow-up.

[Yavaren]

This is nice! Been thinking about pagination too, but this is next level.