feat(design-systems): the master sheet — purpose tokens, not per-element values

Operator's new requirement (#2299, architecture in #2296): a design system does
not just hold tokens, it generates and manages a master CSS sheet. That settles
the milestone's open "authority mechanism" question — the record is
authoritative because the stylesheet comes out of it.

**The sheet is shaped by purpose and styles no elements.** It declares custom
properties, grouped by what they mean, and contains no `.btn-primary`, no
`table`, no `input`. That is the design, not a shortcut: a sheet that styled
elements would restate the same handful of values once per element and grow with
the UI, where purpose-named values are stated once and reused. Components live
as SNIPPETS that reference these names — a surface that already exists and
already carries prose, locations, drift checks, merge and write-path recall.

A token named after an element (`--fs-button-bg`) is the smell that the two have
been mixed; a purpose name (`--fs-action-primary`) is reused across all of them.

Alongside the CSS the endpoint returns what the text cannot say for itself:
which tokens are still valueless, and which VALUES are declared under more than
one name. The second is the operator's "reuse consistent values" constraint made
checkable — and it reports rather than refuses, because a design system
legitimately aligns colours on purpose ("Success = Moss, by design") and only a
human knows which case it is.

Mode maps to selector the way the codebase already does it: base on the root
selector, every other mode layered on `[data-theme="…"]`. The root selector is a
PARAMETER — #251 recorded that a container-scoped preview cannot use `:root`, so
hardcoding it would have made the generator useless to the preview surface.

A token the rulebook names but states no value for is emitted as a commented-out
declaration IN ITS GROUP rather than dropped. Its absence is the finding, and a
comment puts that finding where the reader already is.

Values are validated, not escaped, and this is a real boundary rather than
tidiness: design systems are shareable records (rule #47), so `red; } body {
display: none` in a system shared with you would otherwise inject CSS into your
page. A value containing `{ } ; @ < >`, a comment delimiter or a newline is
REFUSED and rendered as a comment saying so — rejecting beats stripping, since a
partially-sanitised value is one the operator never wrote and the sheet's whole
claim is that it is the record.

Not in scope, and deliberately: serving this as the app's actual stylesheet.
Generating and exposing a sheet is reversible; swapping theme.css for a
generated one is not, and it should be an explicit call rather than a side
effect.

frontend/src/api/designSystems.ts

@@ -159,3 +159,22 @@ export const importFromRulebook = (
     rulebook_id: rulebookId,
     apply,
   });
+
+export interface StylesheetResult {
+  design_system_id: number;
+  /** The master sheet: purpose tokens only, no element or class rules. */
+  css: string;
+  token_count: number;
+  /** Tokens the system names but has no value for yet. */
+  valueless: string[];
+  /** Values declared under more than one name — alias, or one idea twice. */
+  duplicates: Record<string, string[]>;
+}
+
+/** The master CSS sheet a design system generates.
+ *
+ *  Purpose tokens only. Components (buttons, tables, input schemes) are
+ *  snippets that reference these names, so a value is stated once and reused
+ *  rather than restated per element. */
+export const fetchStylesheet = (id: number) =>
+  apiGet<StylesheetResult>(`/api/design-systems/${id}/stylesheet`);