perf(layout): keep Smart Layout's candidate scoring off the main thread

[tomasz-zajac-oss]

Follow-up to #104.

Summary

On the whole bundled sample model, Smart Layout's ELK candidate phase blocked the renderer for ~3.4 s. Profiling showed almost all of that was minimizeCrossings (300–400 ms per candidate × 10), not ELK itself.

• Faster minimizeCrossings. Each swap or shift is scored by only the pairs it can change (localCost), instead of re-scoring the whole group before and after. Costs are exact integer counts, so every accept/reject decision is the same as before.
  • Output was checked against the previous implementation on 55 inputs: sample-model views × 5 engines, synthetic landscapes and 20 random scatters. It was identical on all of them, at 5.9× the speed.
  • This also speeds up Radical Layout, which calls minimizeCrossings on the main thread in the store.
• Scoring in the worker. The main thread now only runs the layout engines (RawCandidate). Crossing minimisation, finalising and scoring of every candidate moved into the Smart Layout worker. runSmartLayoutSAPhase became runSmartLayoutWorkerPhase, and the button shows a new "Scoring layouts… N/10" stage.
• Engines one at a time. Bundled ELK lays out synchronously, so ten queued layouts used to run as one uninterrupted ~220–380 ms block. They now run one at a time with a yield in between, so "N/10 algorithms tried" advances live.

Results

Measured against #104 (ac1a105). "Longest block" is the longest gap between 1 ms event-loop ticks.

Input	Main thread	Longest block	Total
Sample: whole model	3442 → 398 ms	323 → 79 ms	5.1 → 2.6 s
Synthetic, 95 nodes	4570 → 428 ms	337 → 89 ms	6.7 → 3.3 s
Sample: Governance	247 → 224 ms	141 → 52 ms	0.81 → 0.81 s

• Warm runs, i.e. after the first ELK load, block for at most ~40 ms on the whole model.
• The winning layout is byte-identical to fix(layout): make Smart Layout refinement deterministic and never worse #104 on all measured inputs.
• Worker time grew by ~0.5 s on large models because ranking moved there; it runs off the main thread.

Follow-up (not in this PR)

ELK itself still runs on the main thread, which accounts for the remaining ~80 ms cold block. Running it in its own worker (elk-api + elk-worker.min.js) would remove that, but it depends on how Vite/Electron serve the worker script and needs checking in the app.

Test plan

• npm run typecheck
• npm test on top of current main: 432 passed, 2 of them new. One checks that minimizeCrossings never raises the cost; the other checks that the ELK phase only runs the engines, one at a time, reporting each.
• Old vs new minimizeCrossings output identical on 55 inputs.
• Main-thread blocking and result equality measured against fix(layout): make Smart Layout refinement deterministic and never worse #104 on 5 inputs.
• Run Smart Layout in the app on the whole sample model and confirm the UI stays responsive (not done: no app automation available).

🤖 Generated with Claude Code