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/apps/officer-web/frontend.tsx

@@ -5,7 +5,7 @@ import { App } from './App';
 import { seedAppRegistry, seedWidgetRegistry } from 'officerdev';
 import { plugins } from './Plugins.gen';
 import { QueryClient, QueryClientProvider } from '@tanstack/react-query';
-import { ColorModeProvider } from '@/components/ui/ThemeProvider';
+import { InstalledThemes } from '@/state/InstalledThemes';
 import { I18nBridge } from '@/lib/I18nBridge';
 import { Toaster as Sonner } from 'sonner';
 import { TooltipProvider } from '@/components/ui/tooltip';
@@ -32,14 +32,14 @@ const elem = document.getElementById('root')!;
 const app = (
   <StrictMode>
     <QueryClientProvider client={queryClient}>
-      <ColorModeProvider>
+      <InstalledThemes>
         <I18nBridge>
           <TooltipProvider>
             <Sonner position="top-center" toastOptions={{ style: { padding: '16px 20px', fontSize: '16px' } }} />
             <App />
           </TooltipProvider>
         </I18nBridge>
-      </ColorModeProvider>
+      </InstalledThemes>
     </QueryClientProvider>
   </StrictMode>
 );