Drop the output re-parse and the full pre-run snapshot

[IPerception]

web/PERFORMANCE.md backlog items 2 and 3. Four commits, each reviewable on its own.

What changed

Item 2 — stop re-parsing the output. render() rebuilt the browsable document
with parse(result.output), a second full parse producing a second full set of
segment objects for a document processText() already held. It now returns that
document and render() takes it.

Item 3 — snapshot only what changes. processText() cloned every segment before
the rules ran so it could diff afterwards. Each rule now copies a segment on its
first write to it and carries the copy in the mark it already reported, so only
changed segments are ever copied. All three rules had a single mutation site to hook.

processText keeps the first copy per segment: two rules can touch one segment,
and the second rule's copy already contains the first rule's edit, so last-writer-wins
would show a before that never existed in the input file.

sameSegment was kept, as a filter over marked segments rather than a sweep over
all of them. StringReplaceRule counts a match even when the replacement equals it,
so ANYTOWN → ANYTOWN marks every hit and changes nothing; without the filter each
would surface in the Changes tab as a change with identical before and after.

Results

Measured against the same tree with only the change absent, not against the numbers
in the doc — those were taken on another machine.

	before	after
item 2, 50 MB run	2565 ms	1848 ms	−28%
item 3, 100 MB run	5502 ms	4057 ms	−26%
item 3, 125 MB run	10812 ms	6968 ms	−36%

Both were predicted as memory savings and delivered time savings instead. Item 2
was expected to remove "roughly a third of peak heap" and moved the heap column ~2%.
The reasoning error was treating the doc's five copies as five things held at once,
when the two removed were each built and discarded inside a single run. The
out-of-memory ceiling has not moved: 150 MB failed before and still does.

Two things in PERFORMANCE.md were wrong rather than stale, and are corrected with
the measurements: the heap column understated the app (the benchmark discarded the
browsable document the app keeps in state.doc), and it is heap after a forced GC
rather than peak, which is precisely why it could not see either copy.

Correctness

Item 3 moves the correctness of the change list — and of the Limited Data Set's only
record of what it rewrote — onto the accuracy of each rule's marks. Nothing checked
that before, so web/tests/_marks.mjs was added and committed first, passing
against the old behaviour, before anything was removed. It audits both directions for
all three rules, from the suites that already have each rule wired up.

Two tests were verified load-bearing by breaking the code and watching them fail:

• restoring the re-parse fails render.mjs [6]
• flipping to last-writer-wins fails parity.mjs [14] with a fabricated before

node web/tests/all.mjs     # 9 suites, 91 + 132 + 31 checks in the three touched
python -m unittest         # 11 tests

Parity with the Python engine is byte-for-byte unchanged throughout, which is the
property that matters most here: none of this may alter a single byte of output.

🤖 Generated with Claude Code