Re-anchoring editor marks after a whole-file replace: avoid O(marks x gap) by keying lines once and indexing each diff gap

Symptom: after a patience-style line diff, each unmatched mark searched its gap (the unmatched region between matched lines) with filter/normalize/similarity over every gap line. When most lines change, the gap is the whole file, so 50 marks x 10k lines took ~11 s on the main thread and 100k lines took minutes.

Fix (same results on an adversarial test set): 1) Normalize every line once (whitespace-stripped key and space-collapsed key) and pass the arrays into the diff and its alignment helper. 2) Build lazily per gap (keyed by gap start) dictionaries key -> [line indices, in order] for the old and new side, so the k-th-copy-to-k-th-copy lookup is O(copies), not O(gap). 3) For a text that occurs once in each file, use a once-index map instead of a linear firstIndex search. 4) Run fuzzy passes (prefix join/split, Dice similarity) only over the N gap lines nearest the target, generated outward (d=0, then -d/+d) so the nearest-first tie-break is unchanged. Build the mark bigram multiset once. 5) Swift: filtering a String with CharacterSet.whitespacesAndNewlines.contains per scalar is slow; an ASCII fast path (only 9...13 and 32 are ASCII members) helps a lot. Result: 10k lines/50 marks 10.9 s -> 110 ms; 100k/50 >240 s -> 1.2 s.

Testing tip: make the perf check relative (10x lines AND 10x marks vs the small case, threshold ~30x): the quadratic version is ~100x and fails, load does not flake it. Best of 3 on the small side.