Chart theming: user font upload (FontFace-from-IndexedDB) + variable-font weight support

docs/architecture/05-rendering-theming-preview.md

@@ -149,6 +149,8 @@ async function rerender(node: HTMLElement, spec: TopLevelSpec, config: Config) {
   swallow under §7's fail-loud rule). Chart fonts are self-hosted in
   `styles/chart-fonts.css` (offered by the Theme Builder's font control); only
   their latin subsets are precached, the rest runtime-cached (vite.config Workbox).
+  User-uploaded faces are registered on `document.fonts` too, so the same gate
+  resolves them (§3 → User-uploaded fonts).
 - **Do** call `view.finalize()` on every previous view before rendering a new
   one, and on component unmount.
 - **Do** keep exactly one live view per preview node.
@@ -248,6 +250,41 @@ key-by-key), so a snippet can always override or opt out locally. The
 that boundary deliberately: merge bakes the selected theme into `spec.config`
 (spec keys win — rendering unchanged), extract lifts `spec.config` out.
 
+### User-uploaded fonts
+
+Beyond the self-hosted roster, a user can upload font files (`.woff2`/`.woff`/
+`.ttf`/`.otf`) for chart themes. A `FontAsset` (`core/font-asset.ts`) holds the
+raw bytes and persists through the standard entity-store stack — a `fonts`
+IndexedDB store, `infrastructure/font-store.ts` (+ `font-migrations.ts`),
+`stores/FontStore.ts`, `orchestration/font-persistence.ts` — the same
+one-tier-each shape as datasets and custom themes. The browser seam that turns
+stored bytes into a live face, `infrastructure/font-faces.ts`, registers on
+`document.fonts` at startup (before the first render, so the §2 font gate
+resolves user faces like the roster) and on each upload; uploads/deletes are
+orchestrated by `services/fonts.ts`. The Type panel lists user fonts ahead of the
+roster and applies one via the same `applyFontToConfig` transform.
+
+**Font dependencies are derived from the config, never stored on the theme.** A
+`CustomTheme` carries no font field: the family a theme (or a snippet) uses is
+already in its config's `font`/`*Font` slots, that JSON config is the source of
+truth, and snippets use uploaded fonts with no theme to carry such a field. So a
+used face is discovered by scanning configs/specs for the families they reference
+(`collectFontFamilies`, core) and matching against the font library — a stored
+field would only drift from the config it duplicates.
+(Embedding the matched faces' bytes into the §08 workspace export and per-chart
+SVG export is the remaining transfer work, on shared base64 machinery.)
+
+**Variable fonts: weight is the only leverageable axis.** `parseFontAxes` reads
+the OpenType `fvar` table (uncompressed `ttf`/`otf` only — `woff`/`woff2` wrap
+their tables in compression we don't unpack, so those register as static), and a
+variable face is registered with its `wght`→`weight` and `wdth`→`stretch` ranges
+so one file serves the whole weight range, driven by the Type panel's weight
+controls. Only those two axes take effect because Vega's text rendering emits a
+CSS font shorthand (family/size/weight/style) with **no `font-variation-settings`
+hook** — optical size, grade, and custom axes pin at the registered default and
+can't be exposed. Declaring the `wdth` range also defaults the face to normal
+width rather than a variable font's possibly-condensed default instance.
+
 ### Structured controls
 
 The builder's panels — Color, Type, Layout, Axes & grid, Legend