Flaky test: merge-adversarial 10K-lines tokenize times out under parallel pressure

[breferrari]

Symptom

tests/unit/merge-adversarial.test.ts:616 (10K lines with many duplicates tokenize correctly and merge is identity) times out at the configured 60_000 ms when the suite runs under parallel CPU pressure.

Repro

From the repo root, with the tree clean:

```bash
for i in 1 2 3 4; do (npm test 2>&1 > /tmp/full-$i.log) & done
for i in 1 2 3 4 5 6 7 8; do (npm test -- tests/component/flows/ 2>&1 > /tmp/iso-$i.log) & done
wait
grep -E 'Tests +[0-9]+ (passed|failed)' /tmp/full-*.log | sort -u
```

Reliably reproduces 1 fail / 903 pass on each of the 4 full-suite runs. The failure is always the same: token interning stress at 10K lines, timed out at 60s. Isolated npm test -- tests/component/flows/ runs are unaffected.

Pre-existing

Predates the v0.1.x stabilization track. First appears in #48 (feat: core/drift.ts + core/differ.ts — three-way merge engine); the test wasn't added in this PR's branch and isn't related to its changes.

Why now

Surfaced during #111 Phase 1 hardening — the parallel-pressure recipe in `/harden` (4× concurrent full-suite + 8× isolated runs) is sharper than the suite's prior smoke level. With 12 concurrent vitest workers each pushing a per-worker tokenize loop, CPU contention slides 10K-line tokenization past the 60s budget on the slow workers.

Likely fixes

1. Cheapest: bump the per-test timeout to 90 s — keeps the algorithm bounded but accommodates the contended-CPU case. `it('...', () => {}, 90_000)`.
2. Better: shrink the 10K input to the minimum count that still proves the interner's bounded-by-unique-keys invariant (likely 1K is enough); reserve the 10K case for a bench, not a unit test.
3. Best: profile the interner's hot path — if there's an O(n²) anywhere it's the kind of thing the test was meant to catch but is currently measuring, not asserting.

Severity

Low. Doesn't break any production behavior. Surfaces only under parallel-stress; serial `npm test` and CI's matrix runs (one-worker-per-OS) consistently pass.

[breferrari]

Rule-compliance review (2026-04-27)

`/take-next` §4 ("If a test flakes, fix the flake") + Mandatory Declaration #5 ("flakes found during /simplify or /harden get fixed in this PR") were codified after this issue was filed. Retroactive review against the §4 three-condition exception:

1. Confirmed minimal reproducer placing the flake outside the PR's scope — ✅ The flake is in `tests/unit/merge-adversarial.test.ts`. The PR (test(e2e): TUI testing framework extensibility — closes #111 (Phase 3) #117) was scoped to `tests/e2e/tui/`. Different module; no overlap.
2. Fixing would expand scope past the bar PR's bound — ⚠️ Unverified. The flake is a parallel-pressure timeout on the 10K-lines tokenize test. Fix could be a one-line timeout bump, or could indicate an algorithmic issue with the tokenizer under contention. Without investigation, scope-expansion is unknown.
3. User explicitly approved the deferral with full context — ❌ Not at the time. Filing was unilateral; the maintainer flagged it later as a skill violation.

Status: condition 2 is the deciding factor. If the fix is a timeout bump, this issue should close as fix-in-PR. If the fix is algorithmic, this issue stays open as a tracked deferral with retroactive maintainer approval.

Action needed: investigate scope before deciding fix vs keep-deferred. Recommend bundling with the next `tests/unit/` touch.