layout:vectors: 8 fixtures at once through chrome-pool (same vectors)

[thejackshelton]

What changed

• packages/parity/src/cli/vectors.ts: runFixture runs over the layout fixtures 8 at a time. The vectors and the 'skipped' lines are written in fixture order. Each fixture's own cases still run in sequence.

This uses inOrder and CHROME_PAGES from packages/parity/src/chrome-pool.ts (#162). That helper keeps results in item order. After a failure it starts nothing new, lets started items finish, and throws the first failure in item order. Each case already captures in its own browser context, so running cases side by side shares no state.

What passed

• pnpm typecheck: pass, before and after merging origin/master.
• pnpm regen on the branch (job regen-speed-pool-vectors): vectors ran. Fixed point after 1 pass, 0 files changed, git status clean. The outputs are byte-identical. The proof ran before the merge with origin/master, which brought only Chrome captures: pixel, DPR and break captures take 8 cases at once (same bytes) #162's helper itself and other merged work, with no conflicts.
• vectors took 76.6 s, against a median of 68 s over 17 earlier local regens, so this run showed no wall-time gain. The step is partly compile-bound, and its Chrome share is the compiled-side capture only. The machine was under load (the landing driver and other lanes were running), so that wall time is a rough figure, not a benchmark.
• The helper's own behaviour is covered by chrome-pool.test.ts (Chrome captures: pixel, DPR and break captures take 8 cases at once (same bytes) #162).

No tolerance, check, test or fixture changed.

🤖 Generated with Claude Code

[thejackshelton]

PM: closing. The review found that the pool keeps every fixture's full result in memory (vectors are 124 MB on disk), and the step showed no wall-time gain (76.6 s against a 68 s median), because it's compile-bound. The serial loop is kept. A follow-up could stream results inside the pool callback if this step ever becomes a bottleneck.