feat: add validated appearance palettes

docs/THEMING.md

@@ -4,6 +4,9 @@ GovOPlaN supports `system`, `light`, and `dark` as persisted user preferences.
 `system` follows `prefers-color-scheme` live; it is not resolved permanently at
 save time. Core applies the resolved mode through `data-theme` on the document
 root and exposes the selected preference through `data-theme-preference`.
+Each user may also choose a validated `default`, `civic_blue`, `forest`, or
+`plum` accent palette. Core applies it through `data-palette`; every module
+inherits the result through semantic tokens without module-specific CSS.
 
 ## Ownership
 
@@ -12,17 +15,28 @@ root and exposes the selected preference through `data-theme-preference`.
 - Modules consume semantic tokens such as `--surface`, `--text`, `--line`, and
   the status token families. They may define domain aliases whose values resolve
   to shared tokens.
-- User preference selects the mode. Tenant and system policy may provide a
-  future default, but must not silently replace an explicit user choice.
+- User preference selects the mode and palette. Invalid stored palette values
+  fail safely to `default`; the profile API accepts only the supported preset
+  identifiers. Tenant and system policy may provide a future default, but must
+  not silently replace an explicit user choice.
 - Tenant branding is a separate policy surface and must preserve contrast and
   status semantics in both modes.
 
+## Palette safety and scope
+
+The current slice is intentionally user-level. The Settings preview shows the
+chosen accent in every applicable light/dark preview before Save, and Reset
+palette returns the draft to the GovOPlaN default before persistence. Presets
+are checked for WCAG AA contrast in the theme contract. Arbitrary token
+overrides, tenant/system defaults, branding import/export, and policy locks are
+not inferred from this preference and require their own governed follow-up.
+
 Do not introduce fixed foreground/background colors in a module merely to make
 one mode look correct. Add or reuse a semantic Core token, then define both
 light and dark values. Bitmap content and externally authored HTML are exempt,
 but their surrounding controls must still use the shared tokens.
 
-`npm run test:theme-contract` verifies the root behavior and representative
+`npm run test:theme-contract` verifies root mode/palette behavior, preset
+contrast, and representative
 Campaign, Calendar, Files, and Mail token consumption. The check runs before a
 production WebUI build.
-

docs/UI_UX_DECISION_LEDGER.md

@@ -165,13 +165,17 @@ Decision: the WebUI shell exposes a small, stable appearance contract based on
 shared CSS tokens and persisted user preference selection.
 
 - Core applies `system`, `light`, and `dark` preferences at the document root.
+- Core applies validated user accent presets through `data-palette`; palette
+  values change semantic tokens globally and never require module CSS changes.
 - Core owns shared tokens such as `--bg`, `--bar`, `--panel`, `--surface`,
   `--line`, `--line-dark`, `--text`, `--text-strong`, `--muted`, semantic
   status colors, radii, shadows, and disabled-control colors.
 - Modules must style new UI with these tokens and shared controls. Module-local
   CSS may tune layout and spacing, but it must not introduce a separate
   appearance system.
-- Appearance controls live in user settings first. Tenant defaults and policy
+- Appearance controls live in user settings first. The user preference wins
+  over future tenant and system defaults unless a separately documented policy
+  lock is introduced. Tenant defaults and policy
   enforcement can be added later without changing the token contract.
 - Visual preview in settings is illustrative; it must reflect token families,
   not become a second theme implementation.