feat(design): hold the token catalogue to the stylesheet

[haksungjang]

G0-8 of the differentiation plan. CLAUDE.md names design-system.md as the single source of truth for the tokens, which means contributors read it instead of index.css. Nothing checked that the two said the same thing, and they did not.

A token table and a :root block are never in the same diff, and both look right on their own — the same shape as hardening rule #2, where the same vocabulary in two places needs a parity assertion or each side stays green while the pair drifts.

The gate

tokenDocParity.test.ts checks three directions, none of them redundant:

Direction	Catches
doc → css	vocabulary that was only ever promised — G0-7 found three --risk-*-foreground tokens listed as though they had shipped in G0-1, never declared
css → doc	a colour shipped without an entry, which is how the next contributor invents a second token for the same job
EN ↔ KO	a value corrected in one language and not the other, which reads as authoritative in both

A fourth check holds the /* #xxxxxx */ comments beside HSL triples to the values they annotate — a reader scanning the block trusts them, so a stale one is worse than none.

Prose stays out of scope; only tables are parsed. Holding translated sentences to equality would make the gate argue about wording, and a gate that argues about wording gets switched off.

What the first run found

• --muted-foreground documented as #71717a when the stylesheet had moved to #6c6c75 — a W11 accessibility fix the doc never heard about. The contrast figures published beside it (4.63:1, 4.83:1) were the old colour's; the real ones are 4.98:1 and 5.20:1.
• --border / --input documented two channels off (#e5e5ea for a value that renders #e7e7e9), with the stale hex repeated in the stylesheet's own comment.
• --destructive claiming #dc2626, which 0 72% 51% does not produce — it renders #dc2828. The doc and CLAUDE.md both state this token equals --risk-critical, and the status-surface section says in as many words that a red meaning "this went badly" should not be a second, slightly different red. It was one.

Docs move toward the code in the first two cases; the code moves toward the documented design in the third. That is the distinction the gate cannot make for us — it reports that two things disagree, and a person decides which one was the intention.

--destructive renders differently now

0 72% 51% → 0 72% 50.6%, which is #dc2626 on the nose. Two channels, so no screen changes perceptibly, but the destructive button's label contrast goes from 4.60:1 to the 4.63:1 the doc has been publishing. If ui-gates reports a pixel diff, the baselines need a refresh rather than an argument.

Verification

• vitest run — 1670 passed (86 of them this gate's)
• tsc -b --noEmit clean · npm run lint 0 errors · token:lint 123 unchanged · ko-style --fail-on S2 0 findings