perf(html): stream the SourceProcessor walk and recycle completed subtrees - #21595

Bail out of the sync before the safety check on the common token shape (open
stack untouched, nothing completed under the current element), and replace the
O(depth) reconcile scan with a suffix scan, falling back to the full scan only
when a mid-stack open.splice marks the stack dirty.

Corrects the measurement in the previous commit. That 125.1 -> 104.6 ms
compared two separate process runs and does not survive a controlled A/B; in
child-process runs (median of 7) the streamed walk is still slower than the
buffered one, by ~8-25% depending on document shape, after these two fixes cut
it from ~25-35%. Memory is a large win: peak column bytes drop 54-85%.

Still INCOMPLETE - the provisional-end breakage is unfixed.

An element is entered while it is still open, so its end offset and child
links are not final there. Move HtmlGenerator's head/body injection anchors
and its script/link/style/meta collection to exit, where end is final;
script/link/style/meta never nest in each other, so source order is kept.

Cover the streamed contract in the path-accessor test: a completed child
subtree is visited and unlinked while its parent is still open, so child
links read empty from either half of an element's visit - structure is read
from parseHtml's materialized tree instead.

HtmlParser's headLastEnd still reads end on enter. Moving it to exit
regressed 25 CSS-link injection cases, so it needs its own investigation.

A flush only earns its walk setup once enough has piled up under the current
element, so the per-token cost drops from a flush attempt to a subtraction.

Batching alone corrupted the tree: deferring flushes let the allocator rewind
below an element that was still open, so the next mkEl aliased a live node and
produced self-referential links (parent === firstChild === itself), which spun
the walk forever. Route every rewind through _streamRewind, which never
reclaims an id at or below the deepest open element, and only relocate a
held-back trailing text node when it is the sole survivor above its parent so
the id space keeps no gaps.

Found with a temporary link validator (cycle / bad-parent / open-above-count)
run over the html5lib tokenizer corpus plus 6000 seeded fuzz documents:
25612 parses, 0 violations. The differential against the buffered walk is
unchanged at 590 mismatches, now all the inherent end-at-enter class.

Key the per-token gate on the deepest *entered* element rather than the
deepest open one. The open stack changes on every start and end tag, so the
old gate never engaged on shallow markup; keyed this way, an element that
opens and closes inside the batch window is never entered at all and is later
walked as one completed subtree. That is both cheaper and gives its visitors a
final end offset - the differential against the buffered walk drops from 590
mismatches to 14.

Flush a run of children with a single walk instead of a call per child, pick
the run's stop node in O(1) from lastChild, and inline the gate into dispatch
so an idle token costs three loads and a compare.

Batch 4096 balances the two: on the nested benchmark document 6-15% faster
than the buffered walk with ~85% less peak column memory; deep nesting is
neutral. Pathologically flat markup (60k siblings under body) is still 5-13%
slower - what is left there is the per-token gate itself, which stays even
when the batch is raised until the memory win is gone.

A streamed parse recycles each flushed subtree, so it was left to grow from
the default capacity by doubling. A document that keeps everything open (deep
nesting) still reaches the document's size, and doubling into it overshoots
where one exact allocation would not - 5000 nested divs peaked at 0.74 MiB of
columns against the buffered walk's 0.43 MiB.

Apply the same input-length estimate, capped at what one batch can hold, so
deep nesting matches the buffered peak exactly and wide documents keep the
small streamed footprint.

…elocate

_walkSubtree was _walkRun restricted to a single subtree - the printing path
now calls _walkRun directly with the node's own parent and next sibling as the
run bounds, so one walker covers both.

The relocate existed to close the id-space gap a held-back trailing text node
left behind. Since every rewind is clamped by _streamRewind that gap can no
longer be reused by a live node, and dropping it changes nothing measurable:
same 14 differential mismatches, same 2.35 MiB peak, same timings.

Route every open-stack pop through popOpen, which marks the walk dirty, and
have dispatch do one boolean test per token instead of re-deriving the whole
gate. Only a stack change can complete a subtree, so the four-term gate was
being recomputed on every token to answer a question that popOpen already
knows - the CSS grammar gets the same effect from its onRule sink.

The mark cannot do the work itself: an element's end offset is assigned after
it is popped, so syncing inside popOpen visits it with a provisional end (it
regressed the differential to a new mismatch class). The flag defers to the
end of the token, where the end is final.

This closes the flat-markup regression - 60k siblings under body go from
~13-20% slower than the buffered walk to ~6% faster, with peak columns still
roughly halved.

HtmlParser folds a head element's end into its injection anchor at enter and
consumes that anchor in the same visit, so a provisional end there would
misplace injected tags. The streamed walk only starts once the parse reaches
in-body, which is what keeps every head element a completed subtree with a
final end - assert it directly so a change to that guard cannot silently
break head injection.

Restore the path-accessor test to its original enter-only form: entering
lazily and driving the walk from the pops means an element is walked as a
completed subtree, so its child links are live again at enter.

Collapse _streaming / _streamRequested into one flag whose lifetime grammar
owns through try/finally, so a thrown parse can no longer leak streaming into
a later direct parseHtml call and the consume-once dance disappears.

_openSpliced already implies a stack change, so the five sites that set both
now set one and dispatch ORs them.

Split _streamSync into named steps (prefix, close, open, flush) behind a
comment that states the model up front: the walk follows the open element
stack, an element is entered only when something beneath it must be flushed,
and nothing is visited unless _canFlush() holds. Rename _streamSafe to
_canFlush and _streamDirty to _openStackChanged so the vocabulary matches.

No behaviour change: differential unchanged at 14, 452 unit tests pass,
timings within noise.

Streaming every walk cost more than it saved on ordinary pages: a 72 KiB
page is ~4.5k nodes, so the per-token sync and the flushes ran with nothing
to reclaim. Measured against main on a realistic page shape, that was +6.6%
at 142 KiB and +7.1% at 568 KiB, while the memory win only appeared past
~1 MiB per page.

Start the walk unstreamed and switch it on once the document passes
`_STREAM_MIN_NODES`; the first sync enters the open stack and flushes what
already finished. Below the threshold a page is walked once at EOF, which
is what it wanted anyway.

Also stop capping the attribute estimate for a streamed parse. Attribute
ids are never recycled (`_attrCount` only resets between parses), so the
cap just forced the columns through the doubling cascade. The node cap
stays under `_COLUMN_SHRINK_CAPACITY` so a streamed parse's columns are
still reusable by the next parse.

Peak parser columns over six 2.4 MiB pages: 19.2 MiB -> 5.8 MiB. Ordinary
pages are byte-identical to main in both time and memory.

The printer built each node's text from its children's, so the print store
held every node's string until the root was taken — several times the output
for a document of any size, and the reason this branch's walk streaming is
limited to walk-only passes.

A node whose text is exactly `open + children + close` now emits its opener
as it opens and its closer as it exits, and each child goes straight out as
it finishes; the store only ever holds the subtrees that are not of that
shape (a `<pre>` leading newline to round-trip, a `<template>`'s content
fragment, a `/>` whose end tag depends on what printed inside it). An
omitted `<html>` / `<body>` waits in the writer's pending stack, since it
materializes only when the first thing inside it is whitespace.

The walk is unchanged apart from carrying the open path's depth, which is
what lets a node reach the frame its opener was emitted from.

Output is unchanged: byte-identical over the 225 fixture documents and
50,000 random ones, plus the same source map.

Retained heap at the walk's end, and CPU per print (20k-node documents):

  table  12.51 -> 1.47 MiB   105 -> 77 ms
  flat    5.33 -> 0.03 MiB    33 -> 27 ms
  lists   5.23 -> 0.69 MiB    62 -> 51 ms
  deep    1.54 -> 0.62 MiB   5.5 -> 4.7 ms

Three review findings on the walk streaming:

- The JSDoc describing `popOpen` sat above `removeOpenAt`, so one helper was
  documented by a block declaring a return value it does not have and the
  other had none. Moved onto the function it describes.

- Hoisting the walk's state (`_visitors`, `_writer`, the open path, the AST
  columns) to module scope for monomorphic call sites made the grammar
  non-reentrant: a visitor that started another HTML parse would take this
  one's state over and release its columns on the way out, silently. It used
  to work, because the state was per-call. Refuse it with a clear error
  instead. Nesting the other language is untouched — a `<style>`'s CSS has
  its own module state — and an `<iframe srcdoc>` is a separate module
  webpack parses on its own, which is why every `configCases/html` case
  still passes.

- The offsets test was a few dozen nodes against a 49152-node threshold, so
  it never reached the streamed walk it described, and its comment credited
  the wrong mechanism: head elements do not keep final offsets because
  streaming starts in body, but because a flush only ever visits children
  that are already complete, and `HtmlParser` reads `tagEnd()` — assigned at
  insertion — for the still-open `<html>` / `<head>`. Replaced with the
  contrast that does pin the streamed path: the same markup below and above
  the threshold, asserting an entered element reports a provisional `end` at
  `enter` and a final one at `exit`. Verified it bites — pushing the
  threshold out of reach fails it, where the old test passed.

Output is unchanged: the fuzz corpus hashes identically with and without
these commits.