v0.21.0 — Registry-driven composition and sandbox integration

sandbox is eager today: the iframe is created and its dependencies load on page render (it has a height knob but no deferral). That's fine for a small demo, but a heavy sandbox — a three.js scene (WORK-382), a large framework demo — on a perf-sensitive page like the site index costs a chunk of load time we deliberately avoided (WORK-350 and WORK-380 both limited live iframes "to keep the landing page fast").Add a deferred-activation capability so a heavy sandbox can headline a page without the load-time hit — useful for any heavy sandbox, not just three.js.

SPEC-092 Layer 1 — the small first strike that proves the registry-authoring loop. Core registers every page as a page entity but copies only a fixed frontmatter subset (config.ts register hook). Merge the rest of the page's frontmatter onto the page entity's data so any field is queryable by the field-match grammar (which already normalises arrays).

SPEC-092 Layers 2 + 3 — let a page declare a registry type so collection/ aggregate can query it by domain (collection type="rune"), not just type:page.

The generated rune catalogue (WORK-386) needs every /runes/<name> page to carry category, plugin, and status frontmatter. Hand-editing ~100+ pages is a slog and drifts — so backfill it with a script.

The SPEC-092 showcase: the docs site's own rune catalogue, generated from the registry — the page about the runes built from the runes. The dogfood payoff of frontmatter-declared entities, and open-world (a third-party plugin's documented runes join with no change to refrakt).

Frontmatter-driven catalogues can drift from code — add a defineRune without a doc page and it silently vanishes from the generated catalogue. Turn that into a build signal. Fast-follow to the catalogue work.

SPEC-093 core — the build-time data channel from the registry into a sandbox. The registry's third render target (HTML via collection, SVG via aggregate, arbitrary client-side here). Independent of the SPEC-092 track: flat/tree shapes work over the page/pageTree data that exists today.

The launch showcase for the data-bound sandbox — and the simplest, since the data already exists: the core pageTree. A data-shape="tree" sandbox renders the site as a navigable 3D map (three.js tree/force layout); nodes link to their URLs.

The second data-bound showcase — and a dogfood: the plan's own relationship graph. SPEC-072 edges are already live and populated (the plan plugin calls relate() for spec↔work↔decision↔milestone), so this needs no SPEC-092 work.

A generic, content-agnostic section rune: the shared page-section header (eyebrow → headline → blurb → image) followed by an arbitrary body. It exists so a preamble-less grid primitive like bento can be introduced with a title and intro — the role the feature "runes that work together" block plays on the site index today. Unblocks WORK-350 (the bento capstone), which replaces that feature section with a section + bento.

Long-standing leak in the density dimension, surfaced by the SPEC-101 hero-cover docs: sections.css scaled titles with a descendant selector ([data-density="compact"] [data-section="title"] { font-size: 1.25rem }), which punches through nested densities — a full-density hero inside a compact preview renders its headline at 1.25rem, wildly unrepresentative of the real rune. The existing "nested density scoping" resets in density.css covered descriptions and meta ranks but never the title, and a value-based reset can't work for titles (each rune sets its own size).