fix: open documents with many list items without rescanning the file

[Azganoth]

Summary

The list form pass reads every list item's indentation from the start of the item's line back to its marker. It found that line start with lastIndexOf("\n") and lastIndexOf("\r"). When the file had no character of one of those kinds, that search ran back to the start of the file. Files without carriage returns hit this for every item, and so did CR-only files for \n. Opening therefore cost list items times file size: #638 measured 0.9 s of opening a 1 MB document and 22 s, 45%, of a 5 MB one.

readListItemIndent now steps back from the marker to the nearest \n or \r, so finding the line start costs no more than that line. The slice it returns is unchanged.

Related Issue

Closes #674

Verification

• A new markdownCompatibility case opens and saves one document written with LF, CRLF, and CR line endings. The document has an item at offset 0, tab-indented nested items, an item one column off its sibling, and nested lists in a quote. It passes before and after the change, confirming that list form round trips are unchanged for all three line endings.
• In a Node microbenchmark, the old and new lookups were run on 33,334 list items in a 3.6 MB LF string. The old lookup took 26.5 s and the new one 1.2 ms, and both returned the same line starts.
• pnpm check:frontend passed.

Not verified: opening the 5 MB document from #674 in a release build. In the current build, the block gutters' cost (#670) hides this pass.