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]>

core/src/authorization/permissions.ts

@@ -169,6 +169,20 @@ export const CORE_MODULES_CONFIGURATION_MANAGE: PermissionId = parsePermissionId
  */
 export const CORE_DEVICES_MANAGE: PermissionId = parsePermissionId("core.devices.manage");
 
+/**
+ * Authenticated: every signed-in person may read their own name and email and read and change their
+ * own preferences (ADR 0062). Choosing dark mode is not church administration, so it needs no
+ * grant, and a Dashboard where it did would be unusable for its ordinary users. It is a declared
+ * permission rather than a hand-written "is signed in" check, as `core.modules.ui.read` is
+ * (ADR 0026), so the account area is authorized by the same evaluator as everything else.
+ *
+ * **It is self-only by construction.** The routes it guards take the account from the
+ * authenticated session and accept no user id at all, so holding it — whether through the baseline
+ * or a grant — confers no ability to read or change anyone else's account. A device never satisfies
+ * the `authenticated` baseline: a screen in the foyer has no account to read.
+ */
+export const CORE_ACCOUNT_SELF_MANAGE: PermissionId = parsePermissionId("core.account.self.manage");
+
 /**
  * Core's own declarations, exported in deeply immutable form so a trusted composer (the module
  * integration layer, `core/src/modules/permissions.ts`) can build one combined registry from
@@ -207,6 +221,11 @@ export const CORE_PERMISSION_DECLARATIONS: readonly PermissionDeclaration[] = Ob
     description: "Approve display device pairing, list paired devices, and revoke a device.",
     id: CORE_DEVICES_MANAGE,
   }),
+  Object.freeze({
+    baseline: "authenticated" as const,
+    description: "Read your own account and read and change your own preferences.",
+    id: CORE_ACCOUNT_SELF_MANAGE,
+  }),
 ]);
 
 /**