prove the extraction faithful, and fix the one thing that was not

The screenshots said seven dark screens differed and could not say why. Comparing
COMPUTED theme variables between the old build and the new one, in the same colour
mode, answered it in a single run: 47 of 53 matched exactly, and the six that did not
were the `--duck-*` variables — EMPTY in the new build.

The utilities were remapped to `--brand-primary`, `--ink` and friends, which is
correct. What that missed is code reading the VARIABLE rather than using the utility.
`prose.css` does exactly that eleven times — chat markdown links, blockquotes, inline
code, checkboxes — and `landing/styles.css` does it six more. All silently resolved to
nothing.

Fixed by keeping the legacy names as aliases in every theme, pointing at the new
source of truth rather than duplicating values. That also covers any plugin or inline
style doing the same thing, which I have not enumerated. They retire when the utility
rename lands.

Every variable now matches.

── What the screenshots are actually worth here ──

Less than I assumed. The wallpaper rotates per page load, so a control capture of the
same build against itself had 4 of 16 screens differ — and a different 4 each time.
Between 5 and 6 come out byte-identical to the baseline on any run; the rest is noise
I mistook for signal for two rounds, including one where I removed a `color-scheme`
line to test a theory it turned out not to explain.

The variable diff is the instrument that settles it, and it is cheap. Added as
`scripts/theme-vardiff.ts`.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

THEMES-NOTES.md

@@ -103,11 +103,31 @@ was not in tonight's scope.
 
 ---
 
+## On verification, and what the screenshots can and cannot tell you
+
+The byte comparison is **dominated by wallpaper noise**. The dashboard background rotates per page load, so
+any screen showing it differs from itself between runs — a control capture of the same build against itself
+had 4 of 16 differ, and which 4 changes each time. Between 5 and 6 screens come out byte-identical to the
+pre-refactor baseline on any given run; the rest are the wallpaper.
+
+So the authoritative instrument is `scripts/theme-vardiff.ts`, which compares the COMPUTED value of every
+theme variable between the old and new builds in the same colour mode. It reports **all 53 identical**.
+That is a much stronger statement than a screenshot: it says the token layer resolves to exactly the values
+the old stylesheet produced.
+
+It also found the one real regression, which no amount of looking would have: six `--duck-*` variables came
+out EMPTY in the new build. The utilities were remapped, but `prose.css` reads `var(--duck-teal)` DIRECTLY
+in eleven places for chat markdown — links, blockquotes, inline code, checkboxes — and `landing/styles.css`
+does the same. Fixed by keeping the legacy names as aliases in every theme, which also protects any plugin
+or inline style doing the same thing. They retire with the utility rename.
+
 ## Tools built
 
 - `scripts/theme-snapshot.ts` — captures 8 routes × 2 modes, or a pinned theme with `--theme`. Compares two
   directories byte-for-byte. Its first version silently photographed light twice; it now warns when a
   light/dark pair is identical.
+- `scripts/theme-vardiff.ts` — computed theme variables, old build vs new, side by side. The instrument
+  that actually proved the extraction faithful.
 - `scripts/theme-preview-server.ts` — serves this worktree's build against the RUNNING platform's API, so
   the new frontend can be seen with real data without starting a second platform beside the live one.