Make the command palette follow the active desktop theme

[AllTerrainDeveloper]

The Site Assistant / command palette overlay was themed only halfway. Its text tones already read --wpd-fg / --wpd-fg-muted, but the panel itself was a hardcoded rgba( 255, 255, 255, 0.97 ) and every hairline was a literal rgba( 0, 0, 0, … ). Under a dark desktop theme that put the theme's light foreground on a white card — result rows came out nearly invisible.

The search field was worse than untouched. It's a raw <input type="text"> living in the parent shell, so core's forms.css reaches it:

input[type="text"] { background-color: #fff; color: #2c3338; border: 1px solid #8c8f94; … }

That selector weighs (0,1,1) and beat the bare .desktop-mode-ai__input class at (0,1,0), so core painted its own white bordered box with a focus ring — ignoring both the palette and the stylesheet's own chromeless design intent.

What changed — assets/css/ai-assistant.css

• Panel takes --wpd-surface, --wpd-fg and --wpd-border (the hairline ring), plus the desktop-theme DIALOG texture slot. Background is longhand so the texture slot isn't reset by a shorthand.
• Backdrop picks up the SCRIM texture slot alongside the --wpd-scrim colour it already had.
• Every remaining literal border resolves through --wpd-border / --wpd-border-strong, including the ones mixed with the accent via color-mix().
• Input rule scoped to the overlay root — .desktop-mode-ai .desktop-mode-ai__input weighs (0,2,0) and beats core. Same fix as the native-window form-control rule in window-chrome.css. Border, radius, box-shadow and padding are reset; min-height: 30px keeps the hit target core was providing.
• Active mode pill prefers --wpd-surface-elevated so it stays legible against a header that is itself --wpd-surface.

Every token keeps the literal that was already there as its fallback, so an unthemed shell is pixel-identical — with one deliberate exception: the search field now renders chromeless, as its stylesheet always intended.

The three black atmospheric shadows stay literal on purpose: they read as depth against the wallpaper, not as part of the surface.

Docs

• DIALOG / SCRIM slot rows name the command palette as a consumer.
• The --wpd-* palette section notes that body-mounted shell overlays (toasts, dialogs, context menus, the palette) read the palette too.
• The core-CSS note points at both tokenized form-control overrides.

How to test

1. OS Settings → Themes, activate a dark desktop theme.
2. Hit ⌘K, switch to Commands, type something that returns post results.
3. Panel, footer, borders and the search field should all sit in the theme's palette; non-selected result rows must be readable.
4. Deactivate the theme and reopen — everything back to the default look, except the search box, which is now borderless/transparent instead of core's white box.

Checks

npm run build · npm run lint · npm run typecheck · npm run test:js (2448 tests) — all green. No PHP touched.

🤖 Generated with Claude Code

[AllTerrainDeveloper]

it correctly renders the command palette now