feat: add long-haul, the worker-lifetime endurance app

[sheremet-va]

Adds an app that measures what every existing fixture is structurally too short to see: worker-lifetime behavior. Motivated by the vm pool investigation behind vitest-dev/vitest#10854, where a 638-file jsdom suite inverted several conclusions this suite's small apps suggest.

What it is

80 jsdom test files scheduled onto 2 workers, so each worker serves 40 files in one process. Every file's world holds a ~15MB module-level dataset and renders DOM tables over it. The committed config pins vmMemoryLimit: 512MB, so vm pool workers are recycled several times per run on any machine instead of depending on the host's total memory.

What it measures

• Long-run amortization: node pools rebuild the environment and re-import externalized dependencies for every file; vm pool workers pay once and reuse compiled scripts across contexts. This is the first app where the vm pools win by a wide margin (5.9s vs 19.2s against forks on jsdom, Apple M4), the counterweight to the small fixtures where they lose on startup cost.
• The recycle path: no other app ever recycles a worker. A regression that makes recycling expensive (on vmThreads it tears the isolate down in-process, running a full GC over the dead worker's heap) lands in this table.

What it deliberately does not measure

World retention. Workers report lazy heapUsed to the memory-limit check, and V8 collects on its own schedule, so wall clock at this scale cannot distinguish a vitest that releases finished worlds from one that leaks them; that verification lives in Vitest's own reachability regression test (vitest-dev/vitest#10854). The generator header documents this so the fixture's claims stay honest.

Numbers for the README table come from pnpm bench --apps long-haul --runs 3 against the pinned 4.1.10. A run against the #10854 branch build produces the same shape (vm rows within noise, vmForks + happy-dom improves 5.67s to 4.84s).