feat: give every Ekklesia screen one set of design tokens and elements

Modules have owned their own UI since ADR 0021, but the platform has never
said what that UI should look like. Every screen here — the Dashboard shell,
the display host, the module template — invented its own hex colours, font
stack, spacing, and radii, and they already disagreed. A module author had no
vocabulary for "the ordinary panel background", so the only available answer
was to invent one, and two modules would invent two.

Add `@ekklesia/design-tokens`: one validated, enumerable registry of semantic
tokens. A token declares a name, label, description, and default value; its
category and `--ekklesia-*` identifier are derived from the name, so it can
never claim one category while being named for another. Construction rejects
duplicates, malformed names, unknown categories, empty or overlong text, and
any value that is not a bounded literal — no declaration terminator, rule
block, comment, at-rule, `url(`, `!important`, escape, control character, or
markup. A registry that constructs can therefore be emitted as CSS without
escaping, because nothing needing escaping can be in it. That validation is
also what makes a future theme editor implementable rather than aspirational.

Add `@ekklesia/ui`: button, icon button, text input, select, checkbox, field
wrapper, panel, dialog, tabs, table and list primitives, badge, toast, and
empty/error/loading states — every value a token reference, with real
`:focus-visible` treatment and status that never depends on colour alone.
Deliberately small: an element earns its place when two consumers need it.

The stylesheet is a string rather than a `.css` file so the identical bytes
install into a document or an isolated artifact root, and so hover, disabled,
and focus-visible are real CSS rather than JavaScript approximations of them.

`pnpm boundaries` opens exactly two shared roles to modules, by name — every
other role stays rejected — and pins both design packages to the bottom of the
presentation stack. Both are browser-safe by construction, proven by a real
compile of module-shaped source in which `process.env` must fail to typecheck.

The shell installs the defaults at its document root for the Dashboard and the
display; custom properties inherit into module artifacts, so a module reads
`var(--ekklesia-…)` with nothing to import at run time and nothing for a host
to forget to pass.

Co-Authored-By: Claude Opus 5 <[email protected]>

docs/architecture/repository-boundaries.md

@@ -7,7 +7,7 @@ These rules map platform ownership to filesystem and package boundaries. The exe
 | --- | --- | --- |
 | `apps/*` | Thin deployable composition roots | Public Core APIs, generated bootstrap, or a surface as required by the app |
 | `core` | Feature-agnostic platform implementations | Public contracts and external infrastructure libraries |
-| `modules/*` | Domain capability, data, and the module's own UI | Module SDK, module UI SDK, public contracts, React, and external backend libraries |
+| `modules/*` | Domain capability, data, and the module's own UI | Module SDK, module UI SDK, the approved design packages, public contracts, React, and external backend libraries |
 | `surfaces/*` | The application shell, UI, renderers, navigation, and interaction | Surface SDK, API/auth clients, the module UI SDK and host loader, design packages, and a browser framework |
 | `builders/*` | Declarative surface composition tooling | Builder/surface SDKs and public contracts |
 | `packages/*` | Explicitly scoped SDKs, contracts, clients, design, testing, or tooling | Only dependencies appropriate to the package's declared level |
@@ -22,8 +22,8 @@ These rules map platform ownership to filesystem and package boundaries. The exe
   module may therefore contain `.tsx` source and depend on `react`, `react-dom`, and
   `@ekklesia/module-ui-sdk`. It still cannot contain `.jsx`, stylesheets, single-file components,
   Astro/Marko/MDX/HTML views, or SVG presentation assets, and cannot depend on any other UI framework
-  (including `react-router-dom`, `react-native`, and `@vitejs/plugin-react`) or on shared UI-role
-  packages. A module needs no bundler plugin: `@ekklesia/module-ui-build` — a `tooling` package,
+  (including `react-router-dom`, `react-native`, and `@vitejs/plugin-react`) or on any shared role
+  beyond the two approved design packages named below. A module needs no bundler plugin: `@ekklesia/module-ui-build` — a `tooling` package,
   a role modules could already depend on — owns the entire module UI build
   ([ADR 0023](decisions/0023-module-ui-build-pipeline.md)). An unsupported framework aliased behind an allowed name is resolved and rejected by its
   real target.
@@ -31,6 +31,21 @@ These rules map platform ownership to filesystem and package boundaries. The exe
   import Core, an app, a surface, a builder, or another module. It also may not import
   `@ekklesia/module-ui-host`: that package is host infrastructure, and a module bundling the loader
   would blur the author/host split ([ADR 0024](decisions/0024-browser-safe-ui-sdk-and-host-loader.md)).
+- A module may consume exactly two shared **design** roles: `design-tokens` (`@ekklesia/design-tokens`)
+  and `ui` (`@ekklesia/ui`), added by
+  [ADR 0039](decisions/0039-shared-design-tokens-and-elements.md). This is a named allowlist, not a
+  general "browser-safe shared packages are fine" relaxation: `api-client`, `auth-client`,
+  `surface-sdk`, and `module-ui-host` remain rejected inside a module. Both approved packages are
+  browser-safe by construction — `design-tokens` has no dependencies at all and `ui` depends only on
+  it — so a module UI file that imports them still cannot typecheck `process.env`, proven by a real
+  compile under the exact browser project a module uses. Both are also pinned at the bottom of the
+  presentation stack by `design-packages-depend-downward-only`: neither may reach an implementation
+  layer, an API/auth client, or the backend contracts barrel, because a design package that could
+  would put all of it inside every module artifact that renders a button.
+- A module **references** registered global semantic tokens and may derive private,
+  differently-prefixed aliases from them inside its own artifact. It may never define an
+  `--ekklesia-*` custom property: that would invent a global theme variable outside the registry,
+  which a future theme editor could not enumerate and another module could unknowingly depend on.
 - `@ekklesia/module-ui-sdk` has no dependencies at all, and `@ekklesia/module-ui-host` depends only
   on it. Both are browser-safe by construction: neither can pull a backend type graph — and with it
   Node's global declarations — into browser code. Core still owns the containing
@@ -96,6 +111,10 @@ These rules map platform ownership to filesystem and package boundaries. The exe
   direct table imports and foreign keys. Modules may not import another module's Drizzle tables,
   columns, relations, schema entrypoint, or migration internals.
 
+The design packages are covered the same way: one fixture proves a module may depend on both, one
+proves every other shared role stays rejected, and one proves neither design package may depend
+upward.
+
 The boundary test suite includes intentionally invalid fixture graphs. This proves that the guard
 rejects every currently machine-checkable repository rule even before production packages fill
 every directory. The UI guard rejects component, view, template, stylesheet, shared UI-role, and