settings: move the theme/motion panel into @hive/shared, add motion to agent

Review feedback on this PR (mara): "i think the component should be
shared. motion setting is missing." Both addressed:

- `settings-storage.ts` (generic localStorage hook), `theme-apply.ts`,
  `motion-apply.ts`, and `SettingsMenu.tsx`/`.css` all move from
  swarm-ui's `lib/`/`shell/` into `@hive/shared/src/settings/` —
  agent's previous local copies are deleted outright rather than kept
  as a second implementation. One component, `Badge` trigger
  everywhere (already used elsewhere in swarm-ui, so not a new visual
  language there either) — storage keys stay caller-owned (`themeKey`/
  `motionKey` props + matching `useApplyThemeOverride`/
  `useApplyMotionOverride` calls at each package's single mount point)
  so agent and swarm-ui keep fully independent, non-colliding
  persisted settings.
- Agent's settings menu now includes the motion row, matching
  swarm-ui's. No animation in the agent package is gated behind
  `data-motion` yet — same as when swarm-ui first built this plumbing
  ahead of having a consumer — so it's currently inert there, ready for
  whenever agent grows a motion-guarded animation.
- swarm-ui's own theme default flips to `'dark'` as part of this move
  (`theme-apply.ts`'s new default), superseding PR #3715 — that PR
  becomes redundant once this lands and will be closed rather than
  merged, to avoid the two colliding on the same file.

Verified end-to-end with real screenshots on both pages: shared
component renders identically (Badge trigger, theme+motion rows, dark
default) on agent's mock server and a static rebuild of swarm-ui's
dist.

frontend/packages/shared/src/settings/settings-storage.ts

@@ -0,0 +1,79 @@
+// Generic localStorage-backed setting — the shared plumbing a theme
+// override and a reduced-motion override both need ("read a stored
+// value, react to it changing, write a new one") rather than each
+// caller reinventing its own key handling. Not settings-page-specific:
+// any client-local preference reaches for `useLocalSetting` directly.
+// Originated in swarm-ui's own `lib/settings-storage.ts`; moved here
+// once the per-agent page needed the identical mechanism (mara: "i
+// think the component should be shared" — see `SettingsMenu.tsx`'s
+// file comment for the full story).
+//
+// `localStorage`'s own `storage` event only fires in *other* tabs, never
+// the tab that made the write — so two components in the same tab both
+// watching the same key (e.g. `SettingsMenu` writing, a top-level effect
+// reading) need their own same-tab signal. The tiny module-level pub/sub
+// below is that signal; it's deliberately not exported, callers only see
+// the hook.
+import { useEffect, useState } from 'preact/hooks';
+
+const listeners = new Map<string, Set<() => void>>();
+
+function subscribe(key: string, onChange: () => void): () => void {
+  let set = listeners.get(key);
+  if (!set) {
+    set = new Set();
+    listeners.set(key, set);
+  }
+  set.add(onChange);
+  return () => {
+    set!.delete(onChange);
+    if (set!.size === 0) listeners.delete(key);
+  };
+}
+
+function notify(key: string): void {
+  listeners.get(key)?.forEach((fn) => fn());
+}
+
+// Reads outside a component (e.g. an early top-level check) can call
+// this directly; `useLocalSetting` builds on it rather than duplicating
+// the try/catch.
+export function readLocalSetting<T>(key: string, fallback: T): T {
+  try {
+    const raw = localStorage.getItem(key);
+    return raw === null ? fallback : (JSON.parse(raw) as T);
+  } catch {
+    // Private-browsing storage bans, a corrupted value, quota errors —
+    // all the same answer: behave as if nothing were stored.
+    return fallback;
+  }
+}
+
+function writeLocalSetting<T>(key: string, value: T): void {
+  try {
+    localStorage.setItem(key, JSON.stringify(value));
+  } catch {
+    // Best-effort: the setting just won't persist this time, not worth
+    // surfacing an error for a client-local preference.
+  }
+  notify(key);
+}
+
+// `[value, setValue]`, same shape as `useState` — deliberately, so a
+// caller that later needs to swap a plain `useState` for a persisted
+// setting (or vice versa) changes one line, not its whole call site.
+//
+// `setValue` only writes + notifies; it doesn't also call this
+// component's own `setValue` state setter directly. The subscription
+// below already fires for a same-instance write (it's in the same
+// `listeners` set as every other subscriber), so a self-write reaches
+// this component's state through the identical "react to a change"
+// path every other subscriber uses — one path, not two that have to
+// agree.
+export function useLocalSetting<T>(key: string, fallback: T): [T, (value: T) => void] {
+  const [value, setValue] = useState<T>(() => readLocalSetting(key, fallback));
+
+  useEffect(() => subscribe(key, () => setValue(readLocalSetting(key, fallback))), [key]);
+
+  return [value, (next: T) => writeLocalSetting(key, next)];
+}