tw-sweep capture waits for fonts and two frames, as parity's openPage does

[thejackshelton]

Follow-up to #161's Low finding.

What changed

• packages/tailwind-sweep/src/chrome.ts, capture(): after setContent, the page loads Ahem, waits for document.fonts.ready, then waits two frames, as parity's openPage does.
• It then refuses a page whose document.fonts.status is not loaded, so a ch or ex utility can never be measured on a fallback font. That matters now that the sweep runs 8 cold contexts at once.

Tests

• chrome-pages.test.ts, new case: 16 ch/ex boxes against their px equivalents (Ahem: 1ch = 1em, 1ex = 0.8em at the 16px root), on 8 cold pages at once. No box may differ.
• I could not reproduce the race this guards against. The same test also passed 3 times out of 3 with the fix removed: Ahem is a data URI and setContent waits for the load event. So this is a defensive guard; the test pins the behaviour, but it does not catch the race.

What passed

• pnpm typecheck: pass, including after merging origin/master.
• vitest run packages/tailwind-sweep/test/chrome-pages.test.ts packages/tailwind-sweep/test/units.test.ts: 37 passed.
• pnpm regen on the branch (job regen-speed-tw-fonts): only tw-sweep ran, in 221 s. Fixed point after 1 pass, 0 files changed, git status clean. The snapshot is byte-identical.

Note

The text stack adds a similar checkFontsLoaded check in this function, so one of the two will take a small merge.

No tolerance, check, test or fixture changed.

🤖 Generated with Claude Code