Theme exhibition: one demo site, a build per theme, visual QA per theme

The showcase for the #112 catalog: one exhibition site, built once per theme, hosted on GitHub Pages, with agent-driven visual QA gating every theme individually.

## Shape

- **One content tree, exhibition grade.** Grown from the Juno Vale demo: static pages (home, about, now), 6-8 posts exercising everything (code headers with `title=` paths, figures, video facades, callouts, tables, footnotes, search), and a complete portfolio (positions, projects, talks, oss, education) so every theme exhibits the timeline, the careers `/cv/`, `cv.json`, and print. Identical content across themes is the exhibit: same files, different world.
- **A build per theme.** CI matrix: `theme: NAME` + `base_path: /t/NAME/`, ten deterministic builds, `cherry check --strict` each.
- **Hosting: GitHub Pages**, own repo (`holsee/cherry-exhibition`), custom domain `themes.cherrybomb.dev`. Deploy workflow uses the pinned cherry action, one artifact assembling all `/t/NAME/` trees plus the hub.
- **The switcher rides route parity**: every build shares identical routes, so a floating pill swaps `/t/porcelain/PAGE` ⇄ `/t/orbit/PAGE` in place. v1 may ship as a "Themes" nav link to the hub; the pill lands with the theme-local island convention from #112.
- **The hub** doubles as the gallery: light/dark screenshot pairs per theme, CI-generated so it can never lie, each card linking into the live exhibition.

## Per-theme workflow (each theme is its own PR)

1. Build the theme against the exhibition tree; `cherry check --strict` clean.
2. **Full visual QA by the agent** before commit: headless-browser screenshot rounds (Edge/Brave `--headless --screenshot`, verified working) across
- desktop 1280×900 and mobile 390×844,
- light and dark renditions,
- the pages that stress the theme: home, a long post (code headers, callouts, figures), blog index, `/portfolio/` timeline, `/cv/` screen + print stylesheet;
findings fixed in one batch, one confirmation round, then commit.
3. One theme, one commit series, one PR — the exhibition grows theme by theme, and the gallery entry lands in the same PR as its screenshots.

## Why one site, not ten

Ten trees drift, and drift kills the comparison. A runtime theme switcher inside one build would ship every theme's assets to every visitor and misrepresent what cherry actually does — themes resolve at build time.

## Open items

- Exhibition repo scaffolding (repo, domain DNS, deploy workflow) — first PR of the series.
- Whether the demo/site tree in-repo becomes the seed by extraction or by reference (extraction keeps the exhibition under its own gates; the in-repo demo keeps serving the guides).

Tracks the showcase for #112; per-theme issues arrive with their lane infrastructure.

Start by reading the showcase plan for #112 and the open items for the exhibition repo, domain DNS, and deploy workflow. Use the pinned cherry action, the theme matrix, and `cherry check --strict` as the first implementation checkpoints, then run the specified headless-browser screenshot rounds for each theme. Done means one hosted exhibition with identical routes, per-theme builds, visual QA coverage, and a CI-generated gallery hub.

Written by the indexing model from the issue text.