Problem

IncrementalMarkdownCache measures every boundary as an offset into the text it is
handed. It compares those offsets against the blocks parseMarkdownIntoBlocks
returns, and Streamdown hands those back with their line endings already
normalised. On a CRLF reply the two disagree one block in:

parseMarkdownIntoBlocks(remend("para one\r\n\r\npara two\r\n\r\n"))
// ["para one", "\n\n", "para two", "\n\n"]      the source holds "para one\r"

findCommitBoundary matches block 0 at offset 0, advances to 8, then asks whether
the tail continues "\n\n" where it actually holds "\r\n\r\n". The check fails,
repairBroke is set, and update takes the sticky full-document path. From
that point the whole reply is repaired and lexed on every frame, for the rest of
the reply.

A user whose provider or platform emits CRLF gets no incremental rendering at all.

It is not only a cost bug. Streamed at every prefix over a 454 reply corpus, a
CRLF reply's block list already differs from the same reply in LF in 11 of 454
replies on main, and the block count differs in one. After this change it does not
differ in any. So main renders some CRLF replies into a different block list than
the identical LF reply, which is a correctness difference, not a performance trade.
The rest of the difference is time, and nothing in the output says so, which is why
this has survived.

The change

Normalise the line endings at the entry to the cache.

Per the CommonMark spec, "a line ending is a
line feed (U+000A), a carriage return (U+000D) not followed by a line feed, or a
carriage return and a following line feed", and reference parsers normalise to LF
before parsing, so this cannot change what is rendered. A lone carriage return
is included deliberately: a CRLF pair can be split across two frames, and treating
only the pair would leave that CR in place for one frame and delete it the next,
which is one more retro-edit for the cache to absorb.

The scan is a native includes, and the replace runs only for a reply that actually
carries a carriage return.

Measurement

Paired A/B in a single process, both versions of the cache imported side by side and
run alternately so host load lands on both arms, 24 character frames, median of 5
paired ratios.

The ratio grows with the reply because the discarded work is the whole reply each
time. After the change a CRLF reply sits within 1.35x of the same reply in LF; the
gap left is the per-frame preprocessing, not the cache.

Retention over a 454 reply corpus streamed at every prefix:

Exact parity with the LF corpus.

Rendered output is unchanged

454 replies streamed at every prefix in both line endings, comparing the mdast text
and math nodes of the whole document, of every block on its own, and the block count:

Row 1 is the guarantee for the common case: an LF reply is not touched.

Row 2 is the goal, reached: a CRLF reply now renders as the identical block list to
the same reply in LF. The documentText and documentMath columns in that row are
not this cache: that fingerprint is a direct whole-document parse of the CRLF
text, bypassing the cache entirely, and row 3 shows the same 1 and 85 on main.
That is a pre-existing property of parsing CRLF markdown with micromark, unchanged
here in either direction.

Row 3 is the correctness point above, in the table: on main a CRLF reply's block
list diverges from the LF one in 11 replies and the block count in 1. Row 2 shows
both at 0.

The oracle, the cache's block list against a whole-document split at every prefix of
353 CRLF replies: 0 mismatches, comparing against a parse of the normalised text,
which is what a CommonMark parser sees.

Tests

studio/frontend/tests/streaming-crlf-retention.test.ts, three tests. Being explicit
about which are detectors, since a test that passes on the broken tree proves nothing
about the bug:

• a CRLF reply retains as much as the same reply in LF - fails on main
  with CRLF retained 0 characters against LF's 10518. This is the defect. It also
  pins the block list, so retention that returned different blocks would not pass.
• a CRLF reply matches a whole-document split at every prefix - passes on main
  as well. It is the output guard, including a reply ending in a lone carriage
  return, not a defect detector.
• an LF reply is untouched by the line-ending handling - passes on main as
  well, by design: it is the regression guard for the common path.

npm test (3,590 pass), npm run typecheck, npm run build and npx eslint on
both changed files are clean.

Scope

Found while verifying #9017, and deliberately not folded into it: it is a separate,
pre-existing defect that predates that PR, and #9017's own Codex round raised a CRLF
issue in the blank-line scan whose stated CPU consequence turned out to be this,
rather than anything #9017 introduced.