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.

src/scribe/routes/design_systems.py

@@ -114,6 +114,27 @@ async def resolve_design_system(design_system_id: int):
     })
 
 
+@design_systems_bp.get("/design-systems/<int:design_system_id>/stylesheet")
+@login_required
+async def get_design_system_stylesheet(design_system_id: int):
+    """The master CSS sheet this design system generates.
+
+    JSON by default (the UI wants the reuse report alongside the CSS); add
+    `?format=css` for the raw stylesheet as `text/css`, which is what a build
+    step or a `curl` wants.
+
+    `?root=` overrides the base selector — a container-scoped preview cannot use
+    `:root`, so the generator takes it as a parameter.
+    """
+    root = (request.args.get("root") or ":root").strip() or ":root"
+    result = await ds_svc.stylesheet_for_system(_uid(), design_system_id, root)
+    if result is None:
+        return _not_found()
+    if request.args.get("format") == "css":
+        return result["css"], 200, {"Content-Type": "text/css; charset=utf-8"}
+    return jsonify(result)
+
+
 @design_systems_bp.post("/design-systems/<int:design_system_id>/import")
 @login_required
 async def import_design_system(design_system_id: int):