themes are installable, like plugins

`platform/themes/<id>/` — untracked, same rule as `plugins/`, only the instructions
tracked. Drop a directory in and the theme appears in the picker on the next page load.

  themes/my-theme/theme.css     required — `[data-theme='my-theme'] { … }`
  themes/my-theme/theme.json    required — { name, family, dark }
  themes/my-theme/assets/       optional — wallpaper, logo

── Why this is cheaper than installing a plugin ──

A plugin is code: it needs a manifest module, mounting, and a frontend rebuild to reach
the bundler. A theme is a block of CSS custom properties, so it needs none of that. The
server reads the directory at request time and the client adds a `<link>`. No install
step, no rebuild, no restart — which is the whole reason this is eighty lines of
discovery rather than four hundred.

The id is the DIRECTORY NAME, not a manifest field, for the same reason a plugin's
`appName` is not one: an id that can disagree with where its files sit eventually will.
Discovery checks that the CSS actually targets its own directory name, because the
failure is otherwise silent — the theme appears, is selected, and nothing changes.

── Problems are reported, not swallowed ──

A malformed theme returns a reason rather than vanishing:

  broken-probe: theme.css does not target [data-theme='broken-probe']

The client logs those, so an author has somewhere to look instead of wondering why
their theme never appeared.

── Boundaries kept ──

The `theme` package still performs no IO. It gained an `extraThemes` prop; Officer
fetches and injects, exactly as it supplies the panel registry to `workspaces`. A
failure to fetch is not an error — no server, no session, no directory all mean "you get
the built-in themes", which is a complete product.

`/api/themes` is a `core` capability: read-only, and not deniable, because an account
that cannot read the theme list renders unstyled. Installing remains a directory on
disk; an upload endpoint would be a way to write arbitrary CSS into the page from a
request.

Verified in-process: listing, the problem report, CSS served as text/css, and a
traversal attempt answered 404.

── Needs a restart ──

Server-side change. Until then the client's fetch 404s and silently keeps the built-ins,
so nothing breaks in the meantime.

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

src/workspaces/theme/src/ThemeProvider.tsx

@@ -60,10 +60,30 @@ function initialTheme(): ThemeId {
   return DEFAULT_THEME;
 }
 
-export const ThemeProvider = ({ children }: { children: ReactNode }) => {
+export type ThemeProviderProps = {
+  children: ReactNode;
+  /**
+   * Themes installed on the machine, discovered at runtime and merged with the ones this build ships.
+   *
+   * The package does no IO — the host fetches them and injects their stylesheets, exactly as it supplies
+   * the panel registry to `workspaces`. All this needs is their names, so it can list them and so
+   * `isKnownTheme` stops rejecting a perfectly real theme it has never heard of.
+   */
+  extraThemes?: readonly Theme[];
+};
+
+export const ThemeProvider = ({ children, extraThemes }: ThemeProviderProps) => {
   const [themeId, setThemeId] = useState<ThemeId>(initialTheme);
 
-  const theme = useMemo(() => findTheme(themeId) ?? findTheme(DEFAULT_THEME)!, [themeId]);
+  // Shipped first, installed second: a local theme may deliberately replace one of ours by using its id.
+  const all = useMemo<readonly Theme[]>(() => {
+    if (!extraThemes?.length) return THEMES;
+    const byId = new Map(THEMES.map((t) => [t.id, t]));
+    for (const t of extraThemes) byId.set(t.id, t);
+    return [...byId.values()];
+  }, [extraThemes]);
+
+  const theme = useMemo(() => all.find((t) => t.id === themeId) ?? findTheme(DEFAULT_THEME)!, [all, themeId]);
 
   useEffect(() => {
     const root = document.documentElement;
@@ -74,19 +94,23 @@ export const ThemeProvider = ({ children }: { children: ReactNode }) => {
     root.style.colorScheme = theme.applyDarkClass ? 'dark' : 'light';
   }, [theme]);
 
-  const setTheme = useCallback((id: ThemeId) => {
-    if (!isKnownTheme(id)) return;
-    setThemeId(id);
-    try {
-      window.localStorage.setItem(STORAGE_KEY, id);
-    } catch {
-      // Not fatal: the theme still applies for this session, it just will not survive a reload.
-    }
-  }, []);
+  const setTheme = useCallback(
+    (id: ThemeId) => {
+      // Against the MERGED list, not the shipped one: an installed theme is as real as a built-in.
+      if (!all.some((t) => t.id === id)) return;
+      setThemeId(id);
+      try {
+        window.localStorage.setItem(STORAGE_KEY, id);
+      } catch {
+        // Not fatal: the theme still applies for this session, it just will not survive a reload.
+      }
+    },
+    [all],
+  );
 
   const value = useMemo<ThemeContextValue>(
-    () => ({ theme, themeId: theme.id, setTheme, themes: THEMES }),
-    [theme, setTheme],
+    () => ({ theme, themeId: theme.id, setTheme, themes: all }),
+    [theme, setTheme, all],
   );
 
   return <ThemeContext.Provider value={value}>{children}</ThemeContext.Provider>;