feat(eidos): los bloques de tema declaran color-scheme para la superficie que pinta el UA

eidos no emitia color-scheme en ningun sitio: scrollbar-color ya cubre
las barras (archetypes.css), pero la superficie que el UA pinta y eidos
no puede estilar —el popup del <select> nativo, que el catalogo usa de
verdad: month/year select del calendar, format-select de color-field y
color-picker, range-calendar, form-auto-fields— salia BLANCA en oscuro.

Forma: `appearance?: 'light' | 'dark'` en RenderThemeCssOptions, emitido
como primera declaracion DENTRO de los bloques [data-theme] que ya
existian. La opcion viaja por el sitio que renderiza (generated-css.ts),
porque ThemeDefinition no dice si un tema es claro u oscuro. Sin
data-mode nuevo y sin ningun --nombre nuevo: renderGeneratedBaseEidosCss()
emite 5751 nombres unicos antes y despues (8034 ocurrencias; lost=[]
gained=[]), asi que la derivacion de value-channels.test.ts no se mueve.
base.css regenerado en el mismo movimiento: +2 lineas, nada mas.

Verificado en Chrome (servidor propio, /uix): las UNICAS reglas con
color-scheme del documento son las dos de eidos —`:root,
[data-theme='base-light'], [data-theme='light']` → light y
`[data-theme='base-dark'], [data-theme='dark']` → dark— y con
data-theme=base-dark el estilo computado de <html> es `dark`. El popup
nativo no se captura en un screenshot: su efecto se apoya en el contrato
del UA, no en una imagen.

web/routes/active/styles.css:8,65 ya declaraba lo mismo a mano — la
duplicacion se retira cuando se reconstruya routes (congelado hoy). La
via runtime (apply() → renderThemeCss sin appearance) sigue sin emitirlo:
decision de contrato pendiente de firma (ver 598ea460e).

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>

src/uix/eidos/generated/base.css

@@ -9536,6 +9536,7 @@
 :root,
 [data-theme='base-light'],
 [data-theme='light'] {
+	color-scheme: light;
 	--scale-purple-1: #fefcfe;
 	--scale-purple-1: oklch(0.9932 0.0034 325.6);
 	--scale-purple-2: #fbf7fe;
@@ -10252,6 +10253,7 @@
 
 [data-theme='base-dark'],
 [data-theme='dark'] {
+	color-scheme: dark;
 	--scale-purple-1: #18111b;
 	--scale-purple-1: oklch(0.1913 0.0225 315.59);
 	--scale-purple-2: #1e1523;

src/uix/eidos/lib/generated-css.ts

@@ -21,8 +21,8 @@ export function renderGeneratedBaseEidosCss(): string {
  * import it only if you reference raw --scale-{name}-{step} tokens.
  */`,
 		renderStaticCss(config),
-		renderThemeCss(config, 'base-light', { selector: LIGHT_SELECTOR }),
-		renderThemeCss(config, 'base-dark', { selector: DARK_SELECTOR })
+		renderThemeCss(config, 'base-light', { selector: LIGHT_SELECTOR, appearance: 'light' }),
+		renderThemeCss(config, 'base-dark', { selector: DARK_SELECTOR, appearance: 'dark' })
 	].join('\n\n');
 }
 

src/uix/eidos/lib/render-css.ts

@@ -78,6 +78,14 @@ export interface RenderThemeCssOptions {
 	 * on the unemitted scales.
 	 */
 	readonly scales?: 'roleReferenced' | 'all';
+	/**
+	 * Emits `color-scheme: {appearance}` inside the theme block so UA-painted
+	 * surfaces eidos cannot style (the native `<select>` option popup, form
+	 * controls) follow the theme. Omitted → no declaration. Passed by the site
+	 * that renders the block, because `ThemeDefinition` does not say whether a
+	 * theme is light or dark.
+	 */
+	readonly appearance?: 'light' | 'dark';
 }
 
 export interface RenderCssVariablesOptions {
@@ -769,6 +777,10 @@ export function renderThemeCss(
 	);
 	const declarations: string[] = [];
 
+	if (renderOptions.appearance) {
+		declarations.push(`color-scheme: ${renderOptions.appearance};`);
+	}
+
 	const allScaleNames = new Set([...Object.keys(color.scales), ...Object.keys(color.alphaScales)]);
 
 	// Intents omitted from the theme's role map auto-derive from the palette by