extract the visual layer into its own workspace

The application no longer knows what it looks like. It imports one stylesheet and
mounts one provider; every colour, surface and radius lives in `src/workspaces/theme`.

Proven both directions, because either alone would be worthless:

  Duck renders IDENTICALLY to before — checked against screenshots taken before
  anything was touched, not asserted.

  Plain renders as white with black ink, no component edits — panels turn white, the
  teal avatar turns black, the grid fills vanish.

── What moved ──

`globals.css` held three unrelated things: Tailwind wiring, the token contract, and
the Duck brand's hex values. Split along those seams. `base.css` is structure and
names no colour; a theme file is values and nothing else, scoped to
`[data-theme='<id>']`. Adding a theme is a CSS file plus one registry line.

Light and dark are separate themes rather than a mode — the owner's call, and it
removes a concept from the app. Each is written out in full: a theme that only makes
sense as a diff against another cannot be authored by a stranger or sold to a
customer. `.dark` survives only as a per-theme flag, because 396 `dark:` utilities in
33 components resolve against it; retiring those retires the flag.

The `duck-*` utility names are kept for now and pointed at neutral variables, so a
non-Duck theme can define them sensibly. Renaming 1,470 occurrences in the same commit
as the extraction would make any visual difference impossible to attribute. Worth
recording that `duck-dark` was never a brand colour — `#14532d` in light, near-white
in dark, used by 946 components to mean "text". It is `--ink` now.

Surfaces are complete CSS values rather than HSL triplets: `--panel-bg` has to be able
to be a gradient or an image, or the glass the app already has would be unthemeable.

The old provider is a re-export, so its six call sites are untouched and the
extraction stays one variable.

── Bug found by the Plain theme ──

`useThemeSync` stamped the server's `appearance.colorMode` over the local theme on
every load, so choosing Plain and reloading silently reverted it. Diagnosed by asking
the page what it was wearing rather than reasoning: `stored` said `duck-dark` when the
script had written `plain`. The server value is now a starting point for a browser
that has never chosen, not a continuous instruction.

── Tools ──

Two, both of which lied to me before they worked. The snapshot script photographed
light twice and called it a clean run (one browser context, accumulated init scripts);
it now warns when a light/dark pair is identical. The preview server returned the
shell for missing assets, so the logo and wallpaper vanished and read as regressions
in the comparison — it falls through to upstream now.

Dead Tailwind v3 residue deleted: `components/ui/tailwind.{config.ts,css}`, referenced
by nothing, with content globs pointing at a directory that does not exist.

── Not done, deliberately ──

`THEMES-NOTES.md` has the full list. The headlines: the reference repo has not been
read, so the switching mechanism is deliberately the dumbest thing that works; the
wallpaper, panel radius and logo are still component-owned and Plain proves it; and
~985 raw Tailwind palette usages remain, worst in Soulseek.

tsgo clean.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

src/apps/officer-web/state/useThemeSync.ts

@@ -1,13 +1,46 @@
-import { useEffect } from 'react';
-import { useColorMode } from '@/components/ui/ThemeProvider';
+import { useEffect, useRef } from 'react';
+import { useColorMode, useTheme } from '@/components/ui/ThemeProvider';
 import { useSettings } from 'state/useSettings';
 
+/**
+ * Bring the account's saved appearance down from the server, once.
+ *
+ * ── Why "once" is the whole point ──
+ *
+ * This used to re-apply `settings.appearance.colorMode` whenever the settings query resolved, which was
+ * correct while colour mode was the ONLY appearance state — there was nothing else for it to overwrite.
+ * With themes there is: picking Plain and reloading put Plain in localStorage, and then this hook stamped
+ * `colorMode: 'dark'` back over it a moment later. The theme changed and then silently changed back, which
+ * looks like the picker not working.
+ *
+ * So the server's value is treated as what it is — a STARTING POINT for a browser that has never chosen —
+ * rather than as a continuous instruction. A local choice wins, because it is the more recent statement of
+ * what this person wants, and it is already persisted.
+ *
+ * The proper fix is for the server to store a theme id rather than a colour mode, at which point this hook
+ * becomes a one-line sync of the same field in both places. That needs a settings migration and is
+ * deliberately not in the extraction commit.
+ */
+const LOCAL_CHOICE_KEY = 'officer-theme';
+
 export const useColorModeSync = () => {
   const { settings } = useSettings();
   const { setColorMode } = useColorMode();
+  const { themeId } = useTheme();
+  const applied = useRef(false);
 
   useEffect(() => {
-    if (!settings) return;
-    setColorMode(settings.appearance.colorMode);
-  }, [settings?.appearance?.colorMode]);
+    if (!settings || applied.current) return;
+    applied.current = true;
+
+    // This browser has already been told what to wear. The server's colour mode is older information.
+    try {
+      if (window.localStorage.getItem(LOCAL_CHOICE_KEY)) return;
+    } catch {
+      // Storage unavailable — fall through and honour the server, which is the best guess left.
+    }
+
+    const saved = settings.appearance?.colorMode;
+    if (saved === 'light' || saved === 'dark') setColorMode(saved);
+  }, [settings, setColorMode, themeId]);
 };