Bring every colour pair to 4.5:1, and keep it there

[fstubner]

F-tokens-contrast had been sitting at not_evaluated because the app has no design-tokens.json. Extracting one turned out not to be paperwork: eight tokens fail WCAG AA against surfaces they are actually painted on.

What was measured

Not the theoretical cross-product — these are pairs real CSS rules put together:

Theme	Pair	Ratio	Where you see it
dark	--text-muted on --bg-elevated	4.13	the description line under every setting in the Settings dialog
dark	--text-muted on --bg-selected	3.36	muted text on a hovered/selected row
dark	--red on --bg-selected	3.76	the Down label on a hovered interface row
light	--mint on --bg-selected	3.88	the accent, as text — it failed on every light surface
light	--text-muted on --bg-body	4.19
light	--amber on --bg-base	4.34
light	--cyan on --bg-body	4.45

The light theme had drifted furthest, which is what you would expect of the theme nobody looks at. Two of these are in code merged earlier today (#282): the picker's address line is --text-muted on the dialog background, and the red Down label is exactly what a hovered down interface renders.

The fix

Each token moves in lightness only — hue and saturation untouched, so the palette reads the same. Values are the minimum that clears 4.6:1 against every surface, found by search rather than by taste. All 84 foreground×surface combinations now clear 4.5:1.

The guard

scripts/design-tokens.mjs reads tokens.css, checks the cross-product, and generates design-tokens.json. Runs in CI and as npm run test:tokens.

Two decisions worth arguing with:

• The JSON is generated, never hand-written. tokens.css is the single source of truth; a hand-maintained copy drifts, and a drifted copy is worse than none — the contrast gate then passes against values that are not what ships. The check fails if the committed JSON no longer matches its source. (site/design-tokens.json is hand-written and has this defect; it should get the same treatment separately.)
• surface-base maps to the tightest surface per theme, not the nominal base one. --bg-base scored --text-muted at 4.54 while --bg-elevated — the Settings dialog's own background — was at 4.13. Mapping the easy surface would have passed the gate with the dialog still unreadable.

The cross-product is checked rather than an audited list of real pairs. An audited list needs updating whenever a rule pairs a new colour with a new surface, and that update is what gets forgotten. It is stricter than reality, currently satisfied, and needs no maintenance — and it is what found --red on --bg-selected, which was not on my hand-written list.

Verification

• 84 pairs ≥ 4.5:1 across both themes.
• Sabotage-checked: restoring the old --text-muted makes the guard fail with all three of its dark-theme pairs named, and flags the JSON as out of date. Restored, green again.
• The frontend checker now reports SHIP — F-tokens-contrast: 4 pair(s) >= 4.5:1 across 2 theme(s), up from not_evaluated.
• 184 unit tests, tsc exit 0, eslint clean, file-size guard clean, full Tauri render suite green (it asserts themes, and these are colour changes).