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/development/api.md

@@ -79,7 +79,8 @@ No real values are shown here — configure per environment and never commit the
 | `POST\|GET /api/auth/*` | Better Auth (mounted directly) | Supported Better Auth routes retain their native shapes except for the successful email sign-in normalization above. The four denied paths above never reach Better Auth. See [Better Auth's email/password docs](https://www.better-auth.com/docs/authentication/email-password) for supported endpoints such as `/sign-up/email` and `/sign-out`. |
 | `GET /api/v1/principal` | Ekklesia | Returns the minimal `EkklesiaPrincipal` contract as JSON. `Cache-Control: no-store`. |
 | `GET /` | Ekklesia | The built Dashboard page (`surfaces/shell`'s `index.html`), with the API's origin written into it. Served from the API's origin, or from the Dashboard's own hostname through the proxy in the split topology. `no-cache` with a strong `ETag`; framing refused. See [Dashboard host](#dashboard-host). |
-| `GET /assets/ekklesia-dashboard/app.js` | Ekklesia | The Dashboard's one script. `no-cache` with a strong `ETag`; its source map is never served. See [Dashboard host](#dashboard-host). |
+| `GET /assets/ekklesia-dashboard/app.js` | Ekklesia | The Dashboard's application script. `no-cache` with a strong `ETag`; its source map is never served. See [Dashboard host](#dashboard-host). |
+| `GET /assets/ekklesia-dashboard/appearance.js` | Ekklesia | The Dashboard's small pre-paint appearance script, loaded in `<head>`. `no-cache` with its own strong `ETag`. See [Dashboard host](#dashboard-host) and [Account](#account). |
 | `GET /api/v1/health/live` | Ekklesia | Unauthenticated liveness: fixed `200 {"status":"live"}` whenever the process is serving HTTP. `Cache-Control: no-store`; GET only. See [Health](#health). |
 | `GET /api/v1/health/ready` | Ekklesia | Unauthenticated readiness: fixed `200 {"status":"ready"}` only when a bounded database ping succeeds and module startup completed, otherwise `503 {"code":"NOT_READY"}`. `Cache-Control: no-store`; GET only. See [Health](#health). |
 | `GET\|POST /api/v1/grants*` | Ekklesia | Explicit authorization grant management, gated by `core.authorization.grants.manage`. Listing is bounded keyset pagination; creation is unscoped-only and conflicts (`409`) on an equivalent effective grant; revocation clears every unrevoked equivalent. See [Authorization](authorization.md#explicit-grant-http-api). |
@@ -87,6 +88,8 @@ No real values are shown here — configure per environment and never commit the
 | `GET /api/v1/module-realtime/<module-id>/<channel>` | Installed modules | Snapshot-first Server-Sent Events for one registered module-local channel, gated by that channel's declared permission. See [Module realtime](#module-realtime). |
 | `GET /api/v1/module-ui` | Ekklesia | The browser host's module UI inventory: which module UIs may be mounted, where to fetch each, where each module's HTTP and realtime roots live, and the viewer's granted permissions for it. Requires `core.modules.ui.read` (baseline `authenticated`). See [Module UI inventory](#module-ui-inventory). |
 | `GET /api/v1/dashboard/navigation` | Ekklesia | The resolved Dashboard navigation: the same mountable modules, grouped, labelled, and ordered as this installation has configured them. Requires `core.modules.ui.read`. See [Dashboard navigation](#dashboard-navigation). |
+| `GET /api/v1/account` | Ekklesia | The signed-in person's own name, email, and preferences. Requires `core.account.self.manage` (baseline `authenticated`). Takes no user id. See [Account](#account). |
+| `PATCH /api/v1/account/preferences` | Ekklesia | Change some of the signed-in person's own preferences. Requires `core.account.self.manage` and a trusted `Origin`. See [Account](#account). |
 | `PUT\|DELETE /api/v1/dashboard/navigation/{groups,placements}/*` | Ekklesia | Organize the Dashboard: create/rename/order/delete a group, and place a module. Requires `core.dashboard.navigation.manage` (baseline `restricted`) and a trusted `Origin`. See [Dashboard navigation](#dashboard-navigation). |
 | `GET /api/v1/module-ui/<module-id>/<version>` | Ekklesia | Publishes an installed module's validated `entrypoints.ui` artifact at a browser-loadable URL. No authentication; only the declared artifact, never another file. See [Module UI asset publication](#module-ui-asset-publication). |
 | `GET /api/v1/module-ui/<module-id>/<version>/display` | Ekklesia | Publishes the exact validated display artifact for that eligible/running module. Artifact bytes are anonymous trusted code; this route is not the authorization boundary. See [Module display host](#module-display-host). |
@@ -147,14 +150,16 @@ same-origin topology it does so from the same origin as `/api`: `EKKLESIA_DASHBO
 unset, the session cookie stays host-only, and no second static server or proxy file root is
 needed. In the split topology
 ([ADR 0045](../architecture/decisions/0045-split-dashboard-and-api-origins.md)) the proxy forwards
-the Dashboard's own hostname to the same two routes; the API does not inspect `Host`. It works
+the Dashboard's own hostname to the same routes; the API does not inspect `Host`. It works
 exactly like the display host:
 
 - **A closed set of files, read once at startup.** `@ekklesia/shell/dashboard-assets` exports the
-  exact URLs of two built files, `dist/browser/index.html` and
-  `dist/browser/assets/ekklesia-dashboard/app.js`. `startApi()` reads both before importing any
-  module code or binding the listener, and keeps one frozen snapshot of their text with a SHA-256
-  strong `ETag` for each.
+  exact URLs of three built files: `dist/browser/index.html`,
+  `dist/browser/assets/ekklesia-dashboard/app.js`, and the pre-paint
+  `dist/browser/assets/ekklesia-dashboard/appearance.js`
+  ([ADR 0062](../architecture/decisions/0062-account-area-and-synced-appearance-preferences.md)).
+  `startApi()` reads all three before importing any module code or binding the listener, and keeps
+  one frozen snapshot of their text with a SHA-256 strong `ETag` for each.
 - **The API's origin is written in at startup.** The built page carries one empty
   `<meta content="" name="ekklesia-api-origin" />`. Before computing the page's `ETag`, `startApi()`
   fills it with the identity base URL's origin, which is where `/api` lives in either topology. The
@@ -166,33 +171,35 @@ exactly like the display host:
   `DashboardHostAssetError` (`DASHBOARD_HOST_ASSET_UNAVAILABLE`), after closing the resources
   already opened. It never carries a path or the filesystem error. Build the shell first;
   `pnpm api:start` already runs the full build.
-- **Two exact routes, never a directory.** `GET /` answers the page and
-  `GET /assets/ekklesia-dashboard/app.js` answers the script. No request value selects a file, and
+- **Exact routes, never a directory.** `GET /` (and the Dashboard's own pages, ADR 0057) answers
+  the page, `GET /assets/ekklesia-dashboard/app.js` the application script, and
+  `GET /assets/ekklesia-dashboard/appearance.js` the pre-paint script. No request value selects a
+  file, and
   nothing touches the filesystem while answering. Every other path, including `/index.html`,
   `/app.js`, the script's `.map`, and any traversal spelling, falls through to the ordinary
   `404 {"code":"NOT_FOUND"}`. There is no catch-all HTML fallback: the Dashboard has no client
   router, and emailed links land on `/` with a query (see
   [The four anonymous screens](#the-four-anonymous-screens)). Methods other than `GET` (and Hono's
   implicit `HEAD`) are also the ordinary `404`.
-- **No source maps.** The build emits `app.js.map` beside the script, but it is not one of the two
-  files, so it is never served, matching module UI publication (ADR 0025). Browser devtools receive
+- **No source maps.** The build emits `app.js.map` beside the script, but it is not one of the
+  served files, so it is never served, matching module UI publication (ADR 0025). Browser devtools receive
   a `404` for it.
 
 Neither route resolves a principal or reads a cookie, and neither is under `/api/`, so the API's
 CORS policy does not apply. The bytes grant no authority: the page renders sign-in until
 `/api/v1/principal` says otherwise.
 
-| Header | `GET /` | `GET /assets/ekklesia-dashboard/app.js` |
+| Header | `GET /` | `GET /assets/ekklesia-dashboard/app.js` and `appearance.js` |
 | --- | --- | --- |
 | `Content-Type` | `text/html; charset=utf-8` | `text/javascript; charset=utf-8` |
 | `Cache-Control` | `no-cache` | `no-cache` |
-| `ETag` | strong SHA-256 of the page | strong SHA-256 of the script |
+| `ETag` | strong SHA-256 of the page | strong SHA-256 of each script |
 | `X-Content-Type-Options` | `nosniff` | `nosniff` |
 | `X-Frame-Options` | `DENY` | — |
 | `Content-Security-Policy` | `frame-ancestors 'none'` | — |
 | `Referrer-Policy` | `no-referrer` | — |
 
-**Caching.** The shell emits fixed, unhashed file names, so both files are revalidated on every
+**Caching.** The shell emits fixed, unhashed file names, so every file is revalidated on every
 load, exactly like module UI artifacts and the display host's script. A matching `If-None-Match`
 (strong, weak `W/`, a list, or `*`) answers an empty `304` carrying the same `ETag` and
 `Cache-Control`. The page's `304` also carries its security headers, so a revalidated cache entry
@@ -1218,6 +1225,47 @@ platform-global; Ekklesia has no organization or tenant model to scope it to yet
 
 Responses are per-principal, so `Cache-Control: no-store` and `Vary: Origin, Cookie`.
 
+## Account
+
+The signed-in person's own account
+([ADR 0062](../architecture/decisions/0062-account-area-and-synced-appearance-preferences.md)): who
+they are signed in as, and their personal preferences, which follow them to every device.
+
+| Route | Body | `200` answer |
+| --- | --- | --- |
+| `GET /api/v1/account` | none | `{"name":"Ada Lovelace","email":"ada@example.test","preferences":{"appearance":"dark","motion":"system"}}` |
+| `PATCH /api/v1/account/preferences` | `{"appearance":"light"}`, `{"motion":"reduce"}`, or both | `{"appearance":"light","motion":"system"}`, everything now in effect |
+
+- **Self-only by construction.** Neither route accepts a user id in the path, query, or body. The
+  account is always the session's, so no request can read or change anyone else's.
+- **Values.** `appearance` is one of `system`, `light`, or `dark`. `motion` is one of `system`,
+  `reduce`, or `allow`. A person who never chose gets `system` for both.
+- **`PATCH` is partial.** It changes only the preferences it names and keeps the rest, so two devices
+  changing different preferences never overwrite each other. A body that is empty, names any other key,
+  or uses any other value is refused whole with `400 {"code":"INVALID_REQUEST"}`, and nothing is
+  written.
+- **What it returns.** Name and email exactly as the account holds them, and nothing else about the
+  account: no image URL, verification state, timestamps, or user id.
+- **Authority.** Both routes require `core.account.self.manage`, whose baseline is `authenticated`, so
+  every signed-in person may use them with no grant. An anonymous caller or a paired device gets
+  `403 {"code":"AUTHORIZATION_DENIED"}`. The `PATCH` also needs an exact trusted `Origin`
+  (`403 {"code":"UNTRUSTED_ORIGIN"}`) and a body within the Core mutation limit (`413`), both checked
+  before authorization.
+- **Failures.** A person whose session outlived their account gets `404 {"code":"ACCOUNT_NOT_FOUND"}`.
+  A storage failure is a sanitized `503` (`ACCOUNT_READ_FAILED` or `ACCOUNT_WRITE_FAILED`).
+- **Headers.** Responses are `Cache-Control: no-store` and `Vary: Origin, Cookie`.
+
+**Storage.** One row per person in `ekklesia_core_user_preference`, with one typed, `CHECK`-constrained
+column per preference. `null` means never chosen, and deleting the person deletes the row. It is created
+by migration `core:0008_user_preferences`, which an operator applies with `pnpm migrations:apply`. Until
+it is applied, the account routes answer a sanitized `503`, and the rest of the Dashboard keeps working.
+
+**In the browser.** The Dashboard loads the account at bootstrap and applies its preferences through
+the ADR 0060 theme controller. It keeps a two-word copy (`ekklesia.dashboard.appearance` in
+`localStorage`) for one purpose: so `appearance.js` can apply the choice before the first paint. That
+copy is never the source of truth. It is replaced by the account's answer on every load, cleared on
+sign-out, and followed by other open tabs through the browser's `storage` event.
+
 ## Module UI inventory
 
 ```text