Verification round

Independent replication of the claims in the description, plus the surface the
description does not cover.

The defect is real, and narrower than the description implies

Instrumenting findCodeBlockRegions on the merge base:

With two entries the search's first probe is index 0 and lands on the outer span;
with three it probes [1,8], steps right on 9 >= 8, and never visits index 0.

A start-sorted list only mis-steers a binary search when one span contains
another; a partial overlap keeps each span's exclusive part on the correct side of
the pivot. In this function containment can only be an inline span containing a
tilde fence, because /`[^`\n]+`/ cannot span a backtick. That is worth
saying out loud, because it means the reachable input is a single inline code span
holding a complete ~~~...~~~ pair with a $<digits> or a \( after the inner
closer but still inside the span, and the right number of other spans after it. It
also flips on the count of trailing spans rather than monotonically: `~~~a~~~ $5`
differs at 1, 2, 5, 6, 7 and 8 trailing spans, and not at 0, 3 or 4.

Over 20,000 generated realistic-sentence replies, the region list overlapped in 1,552
of them and the output differed in none. I could not build a realistic model reply
that hits this. It is still worth merging: it removes a real invariant violation, it
can only ever protect more code and never less, and it is a landmine for whoever adds
a third region source to this function.

Differential against the merge base

Every difference classified, on the full document and on every streaming prefix:

Three difference classes, all fixes: currency inside such a code span; \(x\) inside
one, which reaches the delimiter-conversion path and turns a code sample into a
rendered formula; and the streaming-prefix forms of both. There is no fourth class.

The strongest check is a third build: the merge base's source with isInRegion
replaced by a linear scan, so it has main's exact region semantics with a correct
membership test. This branch agrees with that oracle on 24.9M prefix evaluations and
1.5M random strings, 0 mismatches, which makes every difference provably "the binary
search returned a false negative" rather than a semantic change. Direction of error
over 5,091,155 membership probes: main gives 8 false negatives and 0 false positives,
this branch 0 and 0.

CommonMark

Per the 0.31.2 spec, block structure is resolved before inline structure (section 3.1)
and a code fence is a line-level construct (section 4.5), so a real parser can never
produce a genuinely overlapping code span and fenced block. Checked against micromark
with the GFM extension, which is what this app renders with: on every input tested,
this branch's merged coverage is byte-identical to main's raw coverage, so the merge
cannot move CommonMark fidelity in either direction. Where the heuristic over-covers,
it already over-covered.

Streaming monotonicity

preprocessLaTeX is not prefix-stable, which is the subject of #9017. This branch
makes it strictly less unstable and never more: over 1,398,087 prefix steps, main
violates on 107,296 and this branch on 106,142, with 1,154 removed and 0 added.

Cross engine and cross checks

• The suite bundled and run in Chromium, Firefox and WebKit agrees case for case with
  Node and with itself, and the same 20 cases differ from main in all three. Playwright
  WebKit is a proxy for the webviews Desktop embeds, not those webviews.
• mergeRegions properties over 900,000 random list pairs: output sorted,
  non-overlapping, coverage equal to the union, inputs not mutated, adjacent spans not
  fused. Its precondition is ascending by start; internal self-overlap is tolerated,
  but a non-ascending input silently drops regions, so that precondition is worth stating
  precisely in the doc comment since nothing enforces it. Both producers are provably
  ascending and internally disjoint: the regexes are declared inside the function so
  lastIndex is fresh, and neither can match empty.
• Performance, interleaved, median of 5: code-heavy 100 KB 0.94x of main, 10,000 inline
  spans 0.85x, realistic 2 KB to 32 KB replies 0.93x to 1.00x. One worst case, a 129 KB
  document with 10,000 inline spans and no fenced block at all, is 1.08x to 1.13x,
  about +0.1 ms, because main's sort sees a single sorted run there while the merge
  always allocates. Not worth a fast path.
• npm test 2,940 pass, npm run typecheck, npm run build and npx eslint clean.
• The four new tests: three fail on main, one passes on both and says so in its own
  comment. Assertion level, 44 assertions and 7 fail on main, all of them inside
  a code span's own text decides its escaping, whatever follows it, which subsumes the
  other two detectors. That test sweeps 1 to 4 trailing spans and only 1 and 2 flip
  today, so narrowing the sweep later would silently disarm it.

Interaction with #9017

They are independent. #9017 changes only IncrementalMarkdownCache, this changes only
latex.ts; they merge cleanly. Streamed over the same 12,067 replies: this branch
differs from main in 922 cases, #9017 in 0, and the two merged differ in exactly the
same 922, with 0 difference between the merged tree and this branch alone. Neither is
ordered on the other.

@codex review

Codex Review: Didn't find any major issues. Keep them coming!

Reviewed commit: faa338862c

Before/after, from two isolated installs

Two Studios built with install.sh --local, one from this PR's merge base
c87fe20e3 and one from the head faa338862, each with its own
UNSLOTH_STUDIO_HOME. One reply, delivered to both as byte-identical synthetic SSE
through a fetch shim, so the two sides render the same characters and the only
variable left is the branch. Model unsloth/Qwen3.5-2B-MTP-GGUF:UD-Q4_K_XL at 4,096
context on both sides, CPU throttled 6x on both sides.

The reply contains the shape from the description: two inline code spans that each
wrap a ~~~...~~~ pair, one trailing code span, and ordinary math and prices around
them.

Read the last two lines of the reply. The model sent

The token `~~~a~~~ $5` marks a price inside code.
The token `~~~b~~~ \(x\)` marks math inside code.

Both are visible because a backslash inside a code span is literal, so the escape the
preprocessor added shows on screen, and the delimiter conversion rewrote a code sample
into something the model never wrote.

Read from the DOM of the same servers that were photographed, so the picture and the
claim cannot disagree:

code_spans:       ["run --seed $1 --limit $2", "~~~a~~~ \\$5", "~~~b~~~ $x$", "x"]
             ->   ["run --seed $1 --limit $2", "~~~a~~~ $5",   "~~~b~~~ \\(x\\)", "x"]
currency_visible: ["$1,200", "$250", "$5", "\\$5"]  ->  ["$1,200", "$250", "$5"]
math_nodes:       ["r_i = y_i - \\hat{y}_i", "L(\\theta) = \\sum_i (y_i - \\theta x_i)^2"]
             ->   unchanged

Everything else on screen is unchanged: the same two KaTeX nodes, the same
$1,200 and $250 in the prose, the same shell fence.

The picture shows that the two differ; the character-level differential in the
verification comment above says which is right.