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/account/schema.ts

@@ -0,0 +1,56 @@
+import { sql } from "drizzle-orm";
+import { check, pgTable, text, timestamp } from "drizzle-orm/pg-core";
+import { ekklesiaCoreUser } from "../identity/schema.js";
+
+/**
+ * Core-owned storage for a person's own preferences (ADR 0062).
+ *
+ * **One row per person, one typed column per preference.** There is deliberately no key/value
+ * table and no JSON column: each preference has a fixed name and a closed set of values, enforced
+ * here by a `CHECK` constraint beneath the application-layer parser
+ * (`parseAccountPreferencesUpdate`), so nothing but a known value can be stored. A new preference is
+ * a new nullable column in a new migration.
+ *
+ * **`null` means "never chosen"**, and is resolved to the platform default when read
+ * (`resolveAccountPreferences`) rather than written as a column default. That keeps "this person
+ * chose System" distinguishable from "this person never chose", and lets a later preference column
+ * arrive without backfilling a value nobody chose — the same reasoning
+ * `ekklesia_core_module_state` follows for its absent rows (ADR 0028). A person with no row at all
+ * has chosen nothing.
+ *
+ * The row belongs to its person: `user_id` is the primary key and cascades on delete, so deleting
+ * an account removes its preferences with it, and no row can exist for a person who does not.
+ *
+ * Personal, not church-wide. Nothing here is branding, a church theme, or an administrator's
+ * decision for anyone else; those are Settings' (ADR 0061).
+ */
+export const ekklesiaCoreUserPreference = pgTable(
+  "ekklesia_core_user_preference",
+  {
+    userId: text("user_id")
+      .primaryKey()
+      .references(() => ekklesiaCoreUser.id, { onDelete: "cascade" }),
+    appearance: text("appearance"),
+    motion: text("motion"),
+    createdAt: timestamp("created_at", { withTimezone: true }).defaultNow().notNull(),
+    updatedAt: timestamp("updated_at", { withTimezone: true }).defaultNow().notNull(),
+  },
+  (table) => [
+    check(
+      "ekklesia_core_user_preference_appearance_check",
+      sql`${table.appearance} is null or ${table.appearance} in ('system', 'light', 'dark')`,
+    ),
+    check(
+      "ekklesia_core_user_preference_motion_check",
+      sql`${table.motion} is null or ${table.motion} in ('system', 'reduce', 'allow')`,
+    ),
+  ],
+);
+
+/** Explicit map passed to Drizzle, mirroring `dashboardSchema` and `moduleLifecycleSchema`. The
+ * user table is included because the account summary reads a person's own name and email from it;
+ * nothing in this domain writes to it. */
+export const accountSchema = {
+  user: ekklesiaCoreUser,
+  userPreference: ekklesiaCoreUserPreference,
+} as const;