fix(theme): consolidate boot apply and Settings picker into shared module

Gemini review surfaced that App.svelte (onMount theme apply) and
SettingsPanel.svelte (theme <select>) hand-rolled their own defaults
and could disagree:

- App.svelte only set data-theme if localStorage had a value, so on a
  fresh install daisyUI fell back to the first theme in app.css (light).
- SettingsPanel.svelte hardcoded a UI default of "dark".

Result: a first-time user saw a light app but a Settings panel that
claimed "dark" was selected. Picking *any* value in the dropdown was
the only way to reconcile reality with the UI.

This commit:
- Adds packages/frontend/src/lib/theme.ts as the single source of truth:
  THEMES list, Theme type, THEME_STORAGE_KEY, DEFAULT_THEME, plus
  loadStoredTheme() and applyTheme() that handle SSR / private-mode /
  bad-value cases.
- Rewires App.svelte's onMount to call applyTheme(loadStoredTheme()),
  so the boot apply always writes a known good theme to the DOM (even
  on fresh installs), matching what Settings will show.
- Rewires SettingsPanel.svelte's picker to use the shared module,
  dropping its duplicate THEMES const, duplicate storage key, duplicate
  apply/persist logic, and the conflicting "dark" fallback.
- Adds 11 unit tests in tests/theme.test.ts covering the
  default-fallback, known/unknown stored values, SecurityError-on-read,
  SSR (no localStorage), DOM-attribute write, persistence round-trip,
  and the "DOM still updates if storage write throws" contract.

The daisyUI plugin block in app.css still lists themes — that's a
CSS-time concern and can't be imported from TS, so it's kept in sync
by convention (noted in the new module's doc comment).

0 files changed, 0 insertions, 0 deletions