feat(ui): design foundation — two themes, shipped type, one card

Sub-project 1 of the redesign. The diagnosis that shaped it: a design system
already existed and was never wired up. src/index.css defined --paper, --ink
and a muted teal with a contract document behind them, while the app painted
itself with shadcn's default white and near-black. Those tokens reached the
screen in exactly two places — the carry meter and the +/- number colours.

TOKENS. Two layers: --budget-* is the app's own vocabulary, defined once per
theme, and shadcn's whole variable set points at it, so every primitive
inherits both themes rather than being fought. Light is cool paper with ink
navy; dark is deep slate, never pure black, because a black ground makes the
hairlines and the carry meter float.

The brand teal is --primary, NOT --accent. That is precisely what the old bug
got wrong: shadcn's --accent is a subtle hover BACKGROUND paired with
--accent-foreground, so a saturated colour there turns every hover into a
coloured slab with unreadable text. src/cssPairs.test.ts now makes the rule
mechanical — redefining either half of a shadcn pair without the other fails
the build, in any block.

CONTRAST was computed, not eyeballed: the weakest text pair is 5.50:1 against
a 4.5:1 requirement, and field borders clear the 3:1 non-text requirement on
both of their backgrounds. Verified afterwards by reading the tokens back out
of the live browser in both themes rather than trusting the arithmetic.

TYPE. Inter and JetBrains Mono, self-hosted (SIL OFL, licences committed
alongside), latin + latin-ext only. Not in index.css: Bun's CSS bundler
resolves every url() from disk and inlines woff2 as base64 — relative or
absolute, and a "file" loader override does not stop it — which made the
stylesheet 303 KB of render-blocking bytes and defeated the unicode-range
subsetting entirely. They are injected at boot from one definition instead,
which is the only arrangement identical in dev and in a subpath build.

THEME TOGGLE cycles system / light / dark, remembers the choice in
localStorage (a per-device display preference does not belong in the exported
budget), keeps following the OS while set to "system", and is applied by a
tiny inline script before first paint so a dark-theme user never sees a white
flash. Every storage access is wrapped: localStorage throws outright in some
configurations, and a theme preference must never stop the app booting.

A REGRESSION I CAUSED AND CAUGHT: renaming --rule to --budget-rule silently
killed the carry meter. An undefined custom property inside linear-gradient()
does not warn, does not throw and does not fall back — the declaration is
invalid, so the element paints nothing. It looked like a missing feature. Only
pixel-sampling a screenshot found it. src/ui/cssTokens.test.ts now fails if any
TypeScript file references a token src/index.css does not define.

Also: one Section/Stat card treatment applied across month, year, summary and
settings; quiet uppercase table headers; row hover; the rule-editing and
purchase-row actions revealed on hover instead of six always-on links; a scroll
fade on the year matrix so it reads as "more to come" rather than clipped; and
"September 2026" instead of "2026-09" as the month heading.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

src/ui/theme.ts

@@ -0,0 +1,70 @@
+/**
+ * Theme preference: light, dark, or follow the system.
+ *
+ * Stored in localStorage rather than in the dataset, deliberately. The dataset
+ * is the owner's budget — it is exported, imported and versioned, and a
+ * per-device display choice does not belong in it. Importing a backup taken on
+ * a desktop should not flip a phone to dark.
+ *
+ * Every storage access is wrapped: localStorage THROWS on access in some
+ * configurations (a browser set to block site data, some private modes), not
+ * merely returning null, and a theme preference must never be the reason the
+ * app fails to boot.
+ */
+
+export const THEME_KEY = "budget2:theme";
+
+/** What the user chose. */
+export type ThemePreference = "light" | "dark" | "system";
+
+/** What that resolves to right now. Only these two reach the DOM. */
+export type ResolvedTheme = "light" | "dark";
+
+const PREFERENCES: readonly string[] = ["light", "dark", "system"];
+
+export function isThemePreference(value: unknown): value is ThemePreference {
+  return typeof value === "string" && PREFERENCES.includes(value);
+}
+
+export function readThemePreference(): ThemePreference {
+  try {
+    const stored = localStorage.getItem(THEME_KEY);
+    return isThemePreference(stored) ? stored : "system";
+  } catch {
+    return "system";
+  }
+}
+
+export function storeThemePreference(preference: ThemePreference): void {
+  try {
+    localStorage.setItem(THEME_KEY, preference);
+  } catch {
+    // A preference that cannot be remembered is a small loss; a crash is not.
+  }
+}
+
+export function prefersDark(): boolean {
+  try {
+    return window.matchMedia("(prefers-color-scheme: dark)").matches;
+  } catch {
+    return false;
+  }
+}
+
+export function resolveTheme(
+  preference: ThemePreference,
+  systemPrefersDark: boolean,
+): ResolvedTheme {
+  if (preference === "system") return systemPrefersDark ? "dark" : "light";
+  return preference;
+}
+
+/**
+ * shadcn's dark palette is keyed on a `.dark` class rather than a media query
+ * (`@custom-variant dark (&:is(.dark *))` in styles/globals.css), so this
+ * class is the single switch for both shadcn's variables and the app's own
+ * `--budget-*` tokens.
+ */
+export function applyResolvedTheme(theme: ResolvedTheme): void {
+  document.documentElement.classList.toggle("dark", theme === "dark");
+}