native controls follow the theme

Nothing set `color-scheme`, so the browser drew every control it renders itself as if the page were
light. On a dark theme a <select>'s dropdown opened as a white sheet with the page's own pale text on
it — unreadable, and unreachable by any utility class, because that list is painted by the browser and
is not in the document.

`color-scheme` is the only thing that reaches it. It also fixes, for free, the other controls with no
styleable interior: date and colour pickers, the spinner on a number input, and default scrollbars
where a theme has not replaced them.

The `dark` class decides it, because that is the signal that exists — 203 of the 231 themes set
applyDarkClass, and the provider puts it on <html> beside data-theme, so the two always agree about the
same element. Both are specificity 0-1-0 and themes import after this file, so a theme that disagrees
can say so. This is a default, not a decision taken away.

Explicit colours on select/option/optgroup underneath, because color-scheme gives the browser's generic
dark rather than the theme's. Where a browser honours them — Firefox, Chrome on Linux and Windows — the
list becomes the theme's own popover surface. Where it does not, Safari and Chrome on macOS use a
genuinely native menu and the scheme carries it, which is a great deal better than white on white.

Base-layer rules, so a utility still wins and `bg-transparent` on a select behaves as it did.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

src/workspaces/theme/css/base.css

@@ -204,6 +204,51 @@
     background-attachment: fixed;
     background-size: cover;
   }
+
+  /*
+    NATIVE CONTROLS FOLLOW THE THEME.
+    ------------------------------------------------------------------------------------------
+
+    Nothing here set `color-scheme`, so the browser drew every control it renders itself as if the page
+    were light — on a dark theme, a `<select>`'s dropdown opened as a white sheet with the page's own
+    pale text on it. Unreadable, and unreachable by any utility class, because that list is painted by
+    the browser and is not in the document.
+
+    `color-scheme` is the only thing that reaches it. It also fixes, for free, the other controls with
+    no styleable interior: date and colour pickers, the spinner on a number input, and default
+    scrollbars where a theme has not replaced them.
+
+    ── Why the `dark` class decides it ──
+
+    It is the signal that exists. 203 of the 231 themes set `applyDarkClass`, and the provider puts the
+    class on <html> beside `data-theme`, so the two are always in agreement about the same element.
+    Both are specificity 0-1-0 and themes are imported after this file, so a theme that disagrees can
+    simply say so — this is a default, not a decision taken away.
+
+    ── And the explicit colours underneath ──
+
+    `color-scheme` gives the browser's generic dark, not the theme's. Where a browser honours colours on
+    `<option>` — Firefox, and Chrome on Linux and Windows — these make the list the theme's own popover
+    surface instead. Where it does not (Safari, Chrome on macOS, which use a genuinely native menu), the
+    scheme above is what carries it, and generic dark is a great deal better than white-on-white.
+
+    A utility still wins: these are base-layer rules, so `bg-transparent` on a select behaves exactly as
+    it did.
+  */
+  :root {
+    color-scheme: light;
+  }
+
+  .dark {
+    color-scheme: dark;
+  }
+
+  select,
+  option,
+  optgroup {
+    background-color: var(--popover);
+    color: var(--popover-foreground);
+  }
 }
 
 /*