Add the account area and account-synced Appearance preferences

Stage 1 PR 6 (ADR 0062). /account shows who is signed in; /account/appearance
chooses System, Light, or Dark and reduced motion (System, Reduce, Allow).

- Core: ekklesia_core_user_preference, one typed, CHECK-constrained,
  nullable column per preference (null = never chosen), migration
  0008_user_preferences (additive), @ekklesia/core/account store, and the
  authenticated-baseline permission core.account.self.manage.
- API: GET /api/v1/account (name, email, preferences) and partial
  PATCH /api/v1/account/preferences, self-only by construction: no user id
  is accepted anywhere; trusted Origin and body limit on the mutation.
- Shell: the account control shows name, email, and initials (never the
  unvetted image URL) and offers Account, Appearance, Sign out; native
  radio groups apply a choice at once through the ADR 0060 controller and
  save it; the server's answer wins and a failed save reverts.
- First paint: a classic, same-origin, render-blocking appearance.js in
  <head> applies a two-word localStorage cache before paint (no inline
  script, CSP unchanged). The account replaces the cache on every load,
  sign-out clears it, and other tabs follow via the storage event.
- Deploy smoke: real-Chromium checks for light/dark, OS emulation,
  overrides, reload persistence, pre-paint, Shadow DOM modules, reduced
  motion, the display staying light, and phone width; the browser
  container gets a 512 MiB /dev/shm so a long session no longer fails
  requests with ERR_INSUFFICIENT_RESOURCES.

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

docs/architecture/platform-architecture.md

@@ -607,7 +607,14 @@ hierarchy in the same sidebar: a landing page, the platform's General, Branding,
 `/settings/<module-id>`. Which of them a person sees is evaluated by the server
 (`GET /api/v1/dashboard/settings`) as presentation hints, while every route behind them keeps its own
 enforcement; the Settings section names are reserved module ids
-([ADR 0061](decisions/0061-settings-hierarchy-and-module-settings-routes.md)). `pnpm boundaries` opens
+([ADR 0061](decisions/0061-settings-hierarchy-and-module-settings-routes.md)). Personal configuration
+lives apart from it, in the account area: `/account` shows who is signed in, and `/account/appearance`
+holds Light, Dark, or System and reduced motion. These preferences belong to the account, stored by
+Core one typed column per preference and served only to their owner (`GET /api/v1/account`,
+`PATCH /api/v1/account/preferences`, `core.account.self.manage`), so they follow the person to every
+device. A small same-origin script in the page's `<head>` applies this browser's cached copy before
+first paint, and the account's answer replaces it on every load
+([ADR 0062](decisions/0062-account-area-and-synced-appearance-preferences.md)). `pnpm boundaries` opens
 exactly two shared roles to modules **by name**, and pins both design packages beneath everything
 else. The Dashboard and display install the defaults at their document root; custom properties
 inherit into every module artifact, so a module reads `var(--ekklesia-…)` with nothing to import at