merge: dev into r1/claude-reset-fix

Brings in the n2/ntfy-notifications feature (ntfy.sh push notifications
with per-event toggles, subagent-suppression flag, topic-only input,
Settings UI, dispatcher + transport + config modules, 12+ new tests),
the header declutter (theme picker + Debug panel moved into Settings /
sidebar), the shared theme boot-apply module, and an a11y label for the
remove-panel button.

No code changes from this branch were touched by the merge — the
overlap was purely textual.

Conflict resolution:

1. HANDOFF.md (add/add conflict). Both branches independently put a
   single-purpose HANDOFF.md at the repo root for their respective
   in-flight feature, matching the existing convention (c351719 did
   the same for this branch; 29bdd00 did the same for ntfy). After
   this merge both features ship, so neither is in-flight anymore.
   Archive both into notes/:
     - notes/wake-schedule-handoff.md     (this branch — git tracks as a
                                           rename from HANDOFF.md)
     - notes/ntfy-notifications-handoff.md (dev — recovered from
                                           MERGE_HEAD before deletion)
   The root HANDOFF.md is intentionally absent post-merge; the next
   in-flight branch will create its own.

2. packages/api/tests/routes.test.ts (auto-merged). dev appended ntfy
   stubs to the vi.mock('@dispatch/core', ...) factory; this branch
   appended a 'Wake schedule routes' describe block at the bottom.
   The two regions don't overlap and the textual auto-merge is correct
   (verified: 6 describe blocks, both mock-stub regions and the new
   describe present, no conflict markers).

Verification on the merge commit:

  bun run test       → 31 files, 495 / 495 passing
                       (was 431 on the branch + 64 from dev)
  bun run check      → biome clean, 156 files
  bun run --cwd packages/frontend typecheck
                     → svelte-check 0 errors, 0 warnings

dev can now fast-forward to this commit:
  git checkout dev && git merge --ff-only r1/claude-reset-fix

1 files changed, 92 insertions, 0 deletions

diff --git a/packages/frontend/src/lib/theme.ts b/packages/frontend/src/lib/theme.ts
new file mode 100644
index 0000000..2b4bad0
--- /dev/null
+++ b/packages/frontend/src/lib/theme.ts
@@ -0,0 +1,92 @@
+/**
+ * Single source of truth for the app's theme picker.
+ *
+ * Two callers care about themes:
+ *  - `App.svelte`'s `onMount`, which applies the persisted theme on boot
+ *    so the first paint is the right color.
+ *  - `SettingsPanel.svelte`'s theme `<select>`, which lets the user
+ *    change theme at runtime.
+ *
+ * Both used to hand-roll their own `localStorage` key, default value,
+ * and DOM-attribute write. That drift produced a real bug: `App.svelte`
+ * left the DOM untouched on first load (so daisyUI fell back to the
+ * first theme in `app.css`, `light`), while `SettingsPanel` showed
+ * `"dark"` as the selected value — UI and reality disagreed until the
+ * user manually picked a theme. Centralizing here closes that gap.
+ *
+ * The theme list also intentionally mirrors the `@plugin "daisyui"`
+ * block in `app.css`. Drift between the two is harmless (a theme name
+ * present here but not in CSS just falls back to the default daisyUI
+ * theme at render time), but they should be kept in sync by hand —
+ * daisyUI's plugin config is a CSS-time concern and can't be imported
+ * from TS.
+ */
+
+export const THEMES = [
+	"light",
+	"dark",
+	"dracula",
+	"night",
+	"nord",
+	"sunset",
+	"cyberpunk",
+	"forest",
+	"cmyk",
+	"coffee",
+	"caramellatte",
+	"garden",
+	"luxury",
+] as const;
+
+export type Theme = (typeof THEMES)[number];
+
+export const THEME_STORAGE_KEY = "dispatch-theme";
+
+/**
+ * The fallback theme used both at first-boot apply (when nothing is
+ * persisted) and as the UI's default-selected value. They MUST match —
+ * if they ever diverged again, the UI would show one theme and the
+ * page would render another.
+ */
+export const DEFAULT_THEME: Theme = "dark";
+
+/**
+ * Read the persisted theme. Returns `DEFAULT_THEME` when nothing is
+ * stored, when access throws (private mode / SecurityError), or when
+ * the stored value isn't one of the known themes. Never throws.
+ *
+ * SSR-safe: if `localStorage` is undefined (e.g. `vite build` during
+ * prerender, if that's ever wired up), returns the default.
+ */
+export function loadStoredTheme(): Theme {
+	try {
+		if (typeof localStorage === "undefined") return DEFAULT_THEME;
+		const raw = localStorage.getItem(THEME_STORAGE_KEY);
+		if (raw && (THEMES as readonly string[]).includes(raw)) {
+			return raw as Theme;
+		}
+		return DEFAULT_THEME;
+	} catch {
+		return DEFAULT_THEME;
+	}
+}
+
+/**
+ * Apply a theme to the live document and persist it. The DOM write is
+ * unconditional (daisyUI keys off `data-theme` on the `<html>`
+ * element); the storage write is best-effort and swallows quota /
+ * SecurityError failures because the session continues to work either
+ * way — only cross-reload persistence degrades.
+ */
+export function applyTheme(theme: Theme): void {
+	if (typeof document !== "undefined") {
+		document.documentElement.setAttribute("data-theme", theme);
+	}
+	try {
+		if (typeof localStorage !== "undefined") {
+			localStorage.setItem(THEME_STORAGE_KEY, theme);
+		}
+	} catch {
+		// Best-effort.
+	}
+}