/*
 * spec-20260914-001-lucayuvdev (C1) — LOS COMPONENTES DE BOOTSTRAP 5, CONTRA LOS TOKENS DE
 * `tokensDeDiseno.css`.
 *
 * ESTA HOJA SE REESCRIBIÓ ENTERA. No se borró: la premisa de que "con las dos generaciones
 * unificadas el parche deja de tener objeto" cayó. Lo que dejó de tener objeto es el MECANISMO
 * viejo, no la hoja.
 *
 * ============================================================================================
 * QUÉ ERA ANTES, Y POR QUÉ YA NO PODÍA SEGUIR SIÉNDOLO
 *
 *   Eran 71 REGLAS GEMELAS TEXTUALES: `.btn-primary{background-color:var(--accent)}`,
 *   `.form-control{...}`, `.modal-content{...}`, copiando el selector exacto de Bootstrap 4 para
 *   ganarle por orden de enlace. Con Bootstrap 5.3.2 servido, la mitad de esos selectores ya no
 *   existe (`.badge-primary`, `.custom-select`, `.close`, `.border-left`) y la otra mitad apunta a
 *   propiedades que la 5.3.2 ya no escribe ahí.
 *
 *   Copiar los gemelos tal cual sobre Bootstrap 5 daba una hoja COMPLETA, CORRECTA A LA VISTA Y SIN
 *   NINGÚN EFECTO. Es uno de los tres contra-controles que Test Design dejó escritos.
 *
 * ============================================================================================
 * QUÉ ES AHORA — UNA CAPA DE OVERRIDE DE CUSTOM PROPERTIES `--bs-*`
 *
 *   Bootstrap 5 pinta cada componente leyendo variables suyas, y esas variables cuelgan en cadena
 *   de un puñado de variables de TEMA. Pisando el eslabón de arriba se tokeniza todo lo que cuelga
 *   de él, sin repetir un solo selector de componente:
 *
 *     --bs-body-bg  ->  --bs-card-bg, --bs-modal-bg, --bs-dropdown-bg, --bs-popover-bg,
 *                       --bs-list-group-bg, --bs-table-bg, el fondo de `.form-control`…
 *     --bs-border-color -> --bs-card-border-color, --bs-table-border-color, `.border*`…
 *     --bs-secondary-color -> `.text-muted`, el `::placeholder` de los inputs…
 *
 *   Por eso esta hoja pasó de 86 selectores a 13: la decisión sigue teniendo UN solo hogar (Q1) y
 *   ahora además se escribe una sola vez por eje de color en vez de una vez por componente (Q2).
 *
 * ============================================================================================
 * EL ORDEN DE ENLACE SIGUE SIENDO EL MECANISMO — LA PREMISA CONTRARIA ES FALSA
 *
 *   Se creyó que con overrides de variables el orden dejaba de importar. NO. Una custom property
 *   cascadea igual que cualquier otra propiedad, y estos overrides se escriben sobre el MISMO
 *   selector que Bootstrap usa (`:root` es 0-1-0, `.btn-primary` es 0-1-0), porque es ahí donde la
 *   variante declara sus variables. El empate de especificidad es idéntico al de antes y lo
 *   resuelve el orden de origen: esta hoja se enlaza DESPUÉS de `bootstrap.min.css`.
 *
 *   Mover el `<link>` una línea antes dejaría esta hoja completa, correcta y sin efecto, igual que
 *   con los gemelos. Hay un caso de PHPUnit que vigila exactamente eso
 *   (`BootstrapTokenizadoServidoTest::test_ac5_para_btn_primary_gana_por_orden_…`).
 *
 * ============================================================================================
 * NO SE DECLARA GEOMETRÍA, NI SELECTORES CON ID, NI `!important` (AC2/AC8)
 *
 *   Sólo color. Nada de `--bs-*-width`, `-radius`, `-padding`, `-gap`, `-font-size`. Ningún `#` en
 *   ningún selector: `mainmenu.css:1015-1023` ya tokenizó `#modalConfirmarLogout .btn-danger` a
 *   mano y un ID gana por especificidad sobre cualquier combinación de clases.
 *
 * ============================================================================================
 * LÍMITE MEDIDO Y DECLARADO — LO QUE ESTA CAPA **NO** ALCANZA
 *
 *   Bootstrap 5 escribe sus CLASES UTILITARIAS con `!important`, y `!important` le gana a cualquier
 *   declaración normal sin importar el orden ni la especificidad. Así que las utilidades cuyo color
 *   NO pasa por una variable de tema quedan FUERA del alcance de esta capa:
 *
 *     .bg-white      -> rgba(var(--bs-white-rgb),…)!important      (9 usos en la app)
 *     .bg-light      -> rgba(var(--bs-light-rgb),…)!important      (5 usos)
 *     .text-dark     -> rgba(var(--bs-dark-rgb),…)!important       (2 usos)
 *     .text-secondary-> rgba(var(--bs-secondary-rgb),…)!important
 *     .text-bg-*     -> RGBA(var(--bs-<color>-rgb),…)!important    (ver el § de abajo)
 *
 *   Los `--bs-*-rgb` esperan un TRIPLETE (`255,255,255`), y los tokens de este proyecto son colores
 *   `oklch()`: no se pueden convertir a triplete de forma estática. Las dos salidas posibles
 *   —agregar tokens en forma de triplete a `tokensDeDiseno.css`, o volver a usar `!important` acá—
 *   son decisiones que ningún AC declara, así que NO se inventaron: quedan devueltas como deuda.
 *
 *   Las que SÍ pasan por variable de tema quedan tokenizadas sin tocar su selector, y por eso sus
 *   gemelos con `!important` se pudieron borrar: `.text-muted` (var(--bs-secondary-color)),
 *   `.border`, `.border-top`, `.border-bottom` (var(--bs-border-color)).
 *
 *   `.border-left` y `.border-right` NO se reescriben: Bootstrap 5 los renombró a `.border-start` y
 *   `.border-end`, y declararlos acá volvería a meter nombres de Bootstrap 4 en la hoja servida
 *   —que es justo lo que el control de generación única de AC1 prohíbe—.
 *
 * ============================================================================================
 * NO SE ENCIENDE `data-bs-theme` (C1)
 *
 *   Bootstrap 5.3 trae tema oscuro propio por `[data-bs-theme=dark]`. NO se usa: el tema de este
 *   proyecto viaja por la clase `.tema-oscuro` sobre `document.body`.
 *   `BootstrapTokenizadoServidoTest::test_c1_el_tema_oscuro_alcanza_a_los_componentes_de_fabrica_tokenizados`
 *   se pondría rojo si alguien emitiera `data-bs-theme` en una blade.
 *
 * ============================================================================================
 * LA PREMISA QUE ESTA HOJA AFIRMABA Y ERA FALSA — spec-20260915-001-lucayuvdev
 *
 *   Hasta el 2026-09-15 el § de arriba terminaba diciendo:
 *
 *     "Como los overrides de acá apuntan a esos tokens, el tema oscuro los alcanza sin que esta
 *      hoja tenga que declarar NADA dos veces."
 *
 *   y el § 1 lo repetía: "el token al que apuntan ya es el que cambia con `.tema-oscuro`, así que
 *   una sola declaración sirve para los dos temas".
 *
 *   ES FALSO, Y NO POR POCO. Una custom property se sustituye AL CALCULAR EL VALOR DEL ELEMENTO
 *   QUE LA DECLARA, y los descendientes heredan el valor YA SUSTITUIDO. Redefinir el token al que
 *   apunta, en un descendiente, NO la vuelve a evaluar. Con la capa entera declarada sobre `:root`,
 *   `--bs-body-bg: var(--surface)` resolvía en `:root` —tema claro— y el `.tema-oscuro` del
 *   `<body>` ya no la alcanzaba. MEDIDO sobre las tres hojas servidas en Chromium: 76 de 83 valores
 *   computados quedaban idénticos en los dos temas. Los 7 que sí cambiaban eran las variantes de
 *   botón, que declaran sobre SÍ MISMAS y por eso resuelven en el elemento (ver § 3).
 *
 *   La regla estaba escrita en este repo desde antes: `React/main.blade.php:122-125` la explica
 *   para justificar por qué `--accent-light` se emite sobre `<html>` y no sobre `.page-wrapper`.
 *   Lo que falló no fue el conocimiento: fue que ninguna guarda medía EFECTO. Las dos que había
 *   afirman sobre el TEXTO de la hoja servida con `preg_match`, y una hoja completa, correcta a la
 *   vista y sin ningún efecto las pasa entera. Ese nivel lo agrega ahora
 *   `resources/js/__tests__/laCapaDeBootstrapAlcanzaElTemaOscuro.test.js`, que abre un navegador de
 *   verdad y pregunta por `getComputedStyle`.
 *
 *   Este párrafo NO se borra junto con el bug: dejar sólo el código arreglado invita a que alguien
 *   "simplifique" el selector de abajo a `:root` otra vez, con el mismo argumento de economía que
 *   produjo esto.
 */

/* ============================================================================================
 * 1. LAS VARIABLES DE TEMA
 *
 * Son las que Bootstrap deja clavadas con un literal y de las que cuelga, por cadena de `var()`,
 * el color de todos los componentes.
 *
 * VAN DECLARADAS EN **CADA ALCANCE DE TEMA**, Y ÉSA ES LA ÚNICA FORMA QUE FUNCIONA. Una
 * indirección por `var()` no cruza sola un límite de tema: el valor se sustituye en el elemento
 * que DECLARA la variable, no en el que la usa (el detalle, con la medición, en el § "LA PREMISA
 * QUE ESTA HOJA AFIRMABA Y ERA FALSA" de la cabecera).
 *
 * PERO NO SE ESCRIBEN DOS VECES: se escriben UNA VEZ bajo una LISTA de selectores. `:root,
 * .tema-oscuro { --bs-body-bg: var(--surface) }` aplica la MISMA declaración a los dos elementos,
 * y cada uno resuelve su `var(--surface)` contra su propio alcance — el `<html>` contra el claro,
 * el `<body>.tema-oscuro` contra el oscuro. Es exactamente el gemelo que hace falta, sin una sola
 * línea duplicada: la decisión sigue teniendo un solo hogar (Q1) y se sigue escribiendo una sola
 * vez por eje de color (Q2). Verificado midiendo, no razonando.
 *
 * QUÉ TIENE QUE APARECER EN ESA LISTA: todo alcance bajo el cual `tokensDeDiseno.css` redefina la
 * paleta. Hoy son dos (`:root` y `.tema-oscuro`); si mañana aparece un tercero —un `@media
 * (prefers-color-scheme: dark)`, un `[data-tema]`— hay que sumarlo acá o ese tercer tema nace
 * congelado en el claro. No es una advertencia suelta: lo vigila
 * `BootstrapTokenizadoServidoTest::test_c1_la_capa_bs_se_declara_en_todos_los_alcances_de_tema`.
 *
 * `--fuente-de-control` se queda SOLO en `:root`, aparte: no es color, no cambia con el tema, y
 * declararlo dos veces sería la duplicación que el resto de este § evita.
 * ============================================================================================ */

:root {
    /* EL ÚNICO NO-COLOR DE ESTA HOJA, Y SOBREVIVE A LA REESCRITURA A PROPÓSITO.
       `spec-20260909-001` lo puso acá como ORIGEN ÚNICO del tamaño de fuente que comparten
       `.form-control` y `.lb-sm`: el punto de aquel AC era que ese número se escriba UNA sola vez
       entre todas las hojas servidas, y `OrigenUnicoDeFuenteYPrimarioDeshabilitadoServidoTest`
       se pone rojo si aparece cero veces o más de una. No es `--bs-*`, así que no entra en la
       prohibición de geometría de AC2, que sólo alcanza a las variables de Bootstrap. */
    --fuente-de-control: 12px;

    /* spec-20260915-002-lucayuvdev (AC10/AC12b) — EL LADO DEL BOTÓN QUE SE ANEXA A UN CONTROL, Y
       EL SEGUNDO NO-COLOR DE ESTA HOJA.
       Los tres botones de la fila de Producto —la lupa de código, el de ampliar descripción y el
       `?` de descuento anidado— venían con TRES mecanismos de tamaño distintos (una clase de
       `<select>`, un `btn-sm` y un `style` inline de 30x30) y se veían de tres tamaños. AC10 pide
       un solo sistema; el valor es 31px porque es el `min-height` que `estilosAWA.css` le da a
       `.form-control`: un botón anexo a un campo tiene que medir lo que el campo.
       POR QUÉ ES UN TOKEN Y NO UN NÚMERO EN LA CLASE: en la forma D que el gate eligió para AC12b,
       el `?` queda ABSOLUTO ENCIMA del campo y el campo le reserva ese ancho con su propio
       `padding-right`. O sea que el ancho del botón y ese padding son UNA SOLA DECISIÓN repartida
       en dos reglas: si el botón crece y el padding no, la cifra de `text-end` vuelve a quedar
       tapada (medido: con botón de 30 y padding de 34 la holgura era +5px). Con el token, las dos
       reglas leen el mismo número y la dependencia queda escrita donde se ve (Q2).
       EL REPARTO ES EL MISMO QUE EL DE `--fuente-de-control`, Y POR LOS MISMOS TRES MOTIVOS
       MEDIDOS (`estilosAWA.css:1-32`): los CONSUMIDORES van en `estilosAWA.css` porque esto es
       geometría y aquella hoja es donde vive la geometría del control; la DECLARACIÓN no puede ir
       ahí porque `PantallaTiendaReact.jsx:3` la importa desde JS y el AC10 de `spec-20260901-001`
       prohíbe `:root` en toda hoja importada desde JS; y tampoco en `tokensDeDiseno.css`, cuya
       cabecera (:21-28) declara que no contiene ni una regla de geometría, `width` con todas las
       letras. Queda este `:root`, que es el que ya hospeda al otro token de dimensión de control. */
    --ancho-del-boton-anexo: 31px;
}

:root,
.tema-oscuro {
    /* --- Cuerpo, bordes y superficies --- */

    /* `--surface` y no `--bg`: de `--bs-body-bg` cuelgan `--bs-card-bg`, `--bs-modal-bg`,
       `--bs-dropdown-bg`, `--bs-popover-bg`, `--bs-list-group-bg` y el fondo de `.form-control`,
       y los gemelos que esta hoja reemplaza pintaban esos seis con `--surface`. El fondo de la
       página lo siguen fijando `mainmenu.css` y `estilosAWA.css`, que es donde vivía antes. */
    --bs-body-bg: var(--surface);
    --bs-body-color: var(--text);
    --bs-emphasis-color: var(--text);
    --bs-secondary-color: var(--text-faint);
    --bs-secondary-bg: var(--bg);
    --bs-tertiary-color: var(--text-faint);
    --bs-tertiary-bg: var(--bg);
    --bs-border-color: var(--border);
    --bs-border-color-translucent: var(--border-soft);

    /* --- Enlaces --- */
    --bs-link-color: var(--accent);
    --bs-link-hover-color: var(--accent-strong);

    /* --- El foco (spec-20260915-002-lucayuvdev, AC1/AC4) ---

       `--accent-halo` ES EL ÚNICO COLOR DEL ACENTO CON ALFA, y lo consumen dos cosas: la variable
       de acá abajo y las reglas gemelas del § 4. Por eso es un token y no una mezcla escrita dos
       veces (Q2).

       LA ALFA SE ARMA CON `color-mix()` Y NO CON `rgba(var(--accent-rgb), α)`: los tokens de este
       proyecto son `oklch()` y no hay triplete que pasarle a `rgba()` — el mismo límite que la
       cabecera de esta hoja ya declara para las utilidades `.bg-*`.

       POR QUÉ VIVE ACÁ Y NO EN `tokensDeDiseno.css`, QUE ES EL HOGAR DE LOS TOKENS DE COLOR (Q1).
       No es preferencia: aquella hoja tiene su juego de tokens CONGELADO por el guard
       `resources/js/__tests__/hojasCustomSinLiteralesNeutros.test.js` ("tokensDeDiseno.css no gana
       ningún token nuevo salvo `--overlay`"), que es de otra spec y no se toca. Medido: con el
       token allá, ese caso se pone rojo. Queda esta hoja, que es la que lo consume, y el mismo
       `:root, .tema-oscuro` que el resto del § — o sea que sigue al tema por el mecanismo que la
       cabecera explica.

       SIN RESPALDO `hex` + `@supports`, A DIFERENCIA DE LOS TOKENS DE AQUELLA HOJA, y la
       degradación queda dicha en vez de simulada: un respaldo sería el primer literal de color de
       esta hoja. En un navegador sin `color-mix()` la declaración queda inválida al computar y el
       halo no se dibuja — el borde de foco, que no lleva alfa, sigue saliendo del acento. O sea
       que se degrada a "sin halo", nunca al azul de fábrica.

       `--bs-focus-ring-color` GOBIERNA `:focus-visible` Y LA UTILIDAD `.focus-ring`, así que
       tokenizarla es correcto y barato. PERO NO CIERRA AC1 POR SÍ SOLA, y queda dicho acá para que
       nadie la lea como si lo hiciera (A-12): `.form-control:focus` y `.form-select:focus` NO la
       leen — la 5.3.2 les clava `#86b7fe` y `rgba(13,110,253,.25)` como literales sobre el
       selector del componente. Ese camino lo repara el § 4, con reglas gemelas de verdad. */
    --accent-halo: color-mix(in srgb, var(--accent) 25%, transparent);
    --bs-focus-ring-color: var(--accent-halo);

    /* --- Código y resaltado --- */
    --bs-code-color: var(--accent-strong);
    --bs-highlight-color: var(--text);
    --bs-highlight-bg: var(--warning-tint);

    /* --- Validación de formularios --- */
    --bs-form-valid-color: var(--success-text);
    --bs-form-valid-border-color: var(--success);
    --bs-form-invalid-color: var(--danger-text);
    --bs-form-invalid-border-color: var(--danger);

    /* --- Las familias `-bg-subtle` / `-border-subtle` / `-text-emphasis` ---
       Son el trío con el que Bootstrap 5.3 pinta alertas, `list-group-item-*` y `table-*`. */
    --bs-primary-bg-subtle: var(--accent-tint);
    /* `var(--accent)` y NO `var(--accent-light)`. Era el único override de esta hoja que nombraba
       directamente el acento CLARO: en tema oscuro dejaba el borde de `.alert-primary` y de
       `.list-group-item-primary` en el índigo del tema claro mientras el resto del componente ya
       era cian. Medido el 2026-09-15. `--accent` es el que sigue al tema. */
    --bs-primary-border-subtle: var(--accent);
    --bs-primary-text-emphasis: var(--accent-strong);

    --bs-secondary-bg-subtle: var(--bg);
    --bs-secondary-border-subtle: var(--border-soft);
    --bs-secondary-text-emphasis: var(--text-muted);

    --bs-success-bg-subtle: var(--success-tint);
    --bs-success-border-subtle: var(--success);
    --bs-success-text-emphasis: var(--success-text);

    --bs-danger-bg-subtle: var(--danger-tint);
    --bs-danger-border-subtle: var(--danger);
    --bs-danger-text-emphasis: var(--danger-text);

    --bs-warning-bg-subtle: var(--warning-tint);
    --bs-warning-border-subtle: var(--warning);
    --bs-warning-text-emphasis: var(--warning-text);

    --bs-info-bg-subtle: var(--info-tint);
    --bs-info-border-subtle: var(--info);
    --bs-info-text-emphasis: var(--info-text);

    --bs-light-bg-subtle: var(--bg);
    --bs-light-border-subtle: var(--border-soft);
    --bs-light-text-emphasis: var(--text-muted);

    --bs-dark-bg-subtle: var(--border-soft);
    --bs-dark-border-subtle: var(--border);
    --bs-dark-text-emphasis: var(--text);

    /* --- Navbar ---
       El shell de AWA no usa `.navbar` (el sidebar es propio), pero `Tienda/TiendaNavbar.jsx` sí. */
    --bs-navbar-color: var(--text-muted);
    --bs-navbar-hover-color: var(--accent);
    --bs-navbar-active-color: var(--accent);
    --bs-navbar-disabled-color: var(--text-faint);
    --bs-navbar-brand-color: var(--text);
    --bs-navbar-brand-hover-color: var(--accent);
    --bs-navbar-toggler-border-color: var(--border);
}

/* ============================================================================================
 * 2. LAS CUATRO VARIANTES DE BOTÓN
 *
 * Acá el override NO puede ir por variable de tema: Bootstrap declara los colores de cada variante
 * como literales sobre el selector de la variante. Pero tampoco hace falta un selector por estado
 * como en Bootstrap 4: en la 5.3 EL ESTADO VIAJA EN EL NOMBRE DE LA VARIABLE
 * (`--bs-btn-hover-bg`, `--bs-btn-active-bg`), y las tres se declaran en la regla base.
 *
 * Por eso lo que en la hoja vieja eran 4 reglas por variante (base, `:hover`, `:active` con sus
 * `:not(:disabled)`, y el `.show > …dropdown-toggle`) acá es UNA sola.
 *
 * `:focus` no lleva override: la 5.3 lo resuelve con `--bs-btn-focus-shadow-rgb`, que espera un
 * triplete y no un color (ver el límite declarado en la cabecera).
 * ============================================================================================ */

.btn-primary {
    --bs-btn-bg: var(--accent);
    --bs-btn-border-color: var(--accent);
    --bs-btn-hover-bg: var(--accent-strong);
    --bs-btn-hover-border-color: var(--accent-strong);
    --bs-btn-active-bg: var(--accent-strong);
    --bs-btn-active-border-color: var(--accent-strong);
    /* El deshabilitado, que en Bootstrap 4 era la regla `.btn-primary.disabled,.btn-primary:disabled`
       y en la 5.3 es esta terna sobre la variante. Mismos tres colores que pisaba aquélla. */
    --bs-btn-disabled-color: var(--surface);
    --bs-btn-disabled-bg: var(--accent);
    --bs-btn-disabled-border-color: var(--accent);
}

.btn-success {
    --bs-btn-bg: var(--success);
    --bs-btn-border-color: var(--success);
    --bs-btn-hover-bg: var(--success-strong);
    --bs-btn-hover-border-color: var(--success-strong);
    --bs-btn-active-bg: var(--success-strong);
    --bs-btn-active-border-color: var(--success-strong);
    --bs-btn-disabled-color: var(--surface);
    --bs-btn-disabled-bg: var(--success);
    --bs-btn-disabled-border-color: var(--success);
}

.btn-warning {
    --bs-btn-bg: var(--warning);
    --bs-btn-border-color: var(--warning);
    --bs-btn-hover-bg: var(--warning-strong);
    --bs-btn-hover-border-color: var(--warning-strong);
    --bs-btn-active-bg: var(--warning-strong);
    --bs-btn-active-border-color: var(--warning-strong);
    --bs-btn-disabled-color: var(--surface);
    --bs-btn-disabled-bg: var(--warning);
    --bs-btn-disabled-border-color: var(--warning);
}

.btn-danger {
    --bs-btn-bg: var(--danger);
    --bs-btn-border-color: var(--danger);
    --bs-btn-hover-bg: var(--danger-strong);
    --bs-btn-hover-border-color: var(--danger-strong);
    --bs-btn-active-bg: var(--danger-strong);
    --bs-btn-active-border-color: var(--danger-strong);
    --bs-btn-disabled-color: var(--surface);
    --bs-btn-disabled-bg: var(--danger);
    --bs-btn-disabled-border-color: var(--danger);
}

/* El outline gris que la hoja vieja ya tokenizaba (`.btn-outline-secondary`). Se conserva para no
   perder cobertura en la mudanza; mismo token `--text-muted` que tenía. */
.btn-outline-secondary {
    --bs-btn-color: var(--text-muted);
    --bs-btn-border-color: var(--text-muted);
    --bs-btn-hover-bg: var(--text-muted);
    --bs-btn-hover-border-color: var(--text-muted);
    --bs-btn-active-bg: var(--text-muted);
    --bs-btn-active-border-color: var(--text-muted);
    --bs-btn-disabled-color: var(--text-muted);
    --bs-btn-disabled-border-color: var(--text-muted);
}

/* ============================================================================================
 * 3 bis. LO QUE LA UNIFICACIÓN PERDIÓ SIN REEMPLAZO — spec-20260915-001-lucayuvdev
 *
 * El § 1 alcanza a todo lo que Bootstrap cuelga de una variable DE TEMA. Lo de acá abajo es lo que
 * la 5.3.2 clava con un LITERAL sobre la raíz del componente, o con un `rgba(var(--bs-*-rgb), α)`
 * que esta capa no puede pisar porque esos `-rgb` esperan un triplete y los tokens del proyecto son
 * `oklch()`. Ninguno cuelga de `--bs-body-bg` ni de sus hermanas, así que el § 1 no los toca.
 *
 * LOS GEMELOS VIEJOS SÍ LOS PINTABAN, y por eso esto es una recuperación y no una función nueva:
 * la hoja anterior a la unificación (`ce372740`) tenía `.dropdown-item.active`,
 * `.list-group-item.active`, `.page-item.active .page-link`, `.table-striped tbody
 * tr:nth-of-type(odd)`, `.table-hover tbody tr:hover`, `.card-header`, `.card-footer` y `.close`.
 * Se recuperan CON EL MECANISMO NUEVO —una custom property por componente— y no copiando el gemelo
 * viejo: sobre Bootstrap 5 la mitad de esos selectores ya no existe.
 *
 * ESTOS BLOQUES **NO** LLEVAN GEMELO DE `.tema-oscuro`, Y ES CORRECTO. La distinción es la misma que
 * rompió el § 1, del otro lado: una variable declarada sobre el SELECTOR DEL COMPONENTE resuelve su
 * `var()` EN EL ELEMENTO DEL COMPONENTE, que está dentro de `.tema-oscuro` y por lo tanto ve la
 * paleta oscura. Es exactamente por eso que las cuatro variantes de botón del § 2 fueron las
 * ÚNICAS 7 mediciones que seguían al tema cuando todo lo demás estaba congelado. Agregarles un
 * gemelo `.tema-oscuro` no arreglaría nada y subiría la especificidad sin motivo.
 * ============================================================================================ */

/* El estado ACTIVO, que Bootstrap 5.3.2 clava en `#0d6efd` en tres componentes distintos. Es el
   azul que se veía en la app: no es ninguno de los dos acentos del proyecto (`--accent-light:
   #4f46e5` índigo, `--accent-dark: #0891b2` cian), es el de fábrica. Gemelos viejos:
   `.dropdown-item.active,.dropdown-item:active`, `.list-group-item.active` y
   `.page-item.active .page-link`. */
.dropdown-menu {
    --bs-dropdown-link-active-bg: var(--accent);

    /* spec-20260915-002-lucayuvdev (AC6) — EL HOVER DE LAS OPCIONES. Bootstrap 5.3 lo pinta con
       `--bs-dropdown-link-hover-bg: var(--bs-tertiary-bg)`, o sea el gris de fábrica: el § 1 ya
       tokeniza `--bs-tertiary-bg` a `--bg`, así que el hover quedaba del color del fondo de la
       página y casi no se notaba. Va `--accent-tint` y no `--accent`: el AC pide "el acento o una
       versión clara del acento", y un fondo de acento pleno dejaría el texto del ítem —que sigue
       `--bs-body-color`— ilegible encima. Por eso el par viaja completo: el tinte de fondo con el
       color de texto que el sistema de diseño declara PARA ese tinte. */
    --bs-dropdown-link-hover-bg: var(--accent-tint);
    --bs-dropdown-link-hover-color: var(--accent-tint-text);
}

.list-group {
    --bs-list-group-active-bg: var(--accent);
    --bs-list-group-active-border-color: var(--accent);
}

.pagination {
    --bs-pagination-active-bg: var(--accent);
    --bs-pagination-active-border-color: var(--accent);
}

/* LAS DOS FILAS DE LA TABLA. Bootstrap 5.3 las pinta con `rgba(var(--bs-emphasis-color-rgb), .05)`
   y `…, .075)`: un velo NEGRO translucido. Sobre el tema claro se lee como un gris suave; sobre el
   oscuro OSCURECE una superficie ya oscura y la fila se pierde — que es, palabra por palabra, el
   modo de falla que el comentario del gemelo viejo ya nombraba antes de que la unificación lo
   borrara, y lo que el AC4 de `spec-20260908-001` exige que no pase.
   Los dos tokens son OPACOS y distintos entre sí, así que el hover se sigue notando sobre la fila
   alterna. Mismos dos tokens que tenían los gemelos. */
.table {
    --bs-table-striped-bg: var(--border-soft);
    --bs-table-hover-bg: var(--border);
}

/* La cabecera y el pie de la tarjeta. `--bs-card-cap-bg: rgba(var(--bs-body-color-rgb), .03)`, otro
   velo por triplete. Gemelos viejos `.card-header` / `.card-footer`, mismo token. */
.card {
    --bs-card-cap-bg: var(--border-soft);
}

/* LA X DE CERRAR, Y POR QUÉ ES LA ÚNICA REGLA DE ESTA HOJA QUE NO DECLARA UN COLOR.
   El gemelo viejo era `.close { color: var(--text) }` y PINTABA, porque en Bootstrap 4 la X es un
   carácter de texto. En la 5.3 `.btn-close` la dibuja con un SVG de fondo que lleva el negro
   incrustado en la data-URI (`fill='%23000'`), así que ningún `color` la alcanza y no hay custom
   property de color que sirva: `--bs-btn-close-color` existe pero no pinta nada.
   La única palanca es la que Bootstrap usa para su PROPIO tema oscuro, y se reutiliza tal cual en
   vez de inventar un filtro nuevo o meter otra data-URI con un hex literal — que sería el primer
   literal de color de la hoja. `filter` no es geometría, así que no entra en la prohibición de
   AC2; el selector no tiene ningún `#`, así que tampoco en la de AC8.
   Va acotado a `.tema-oscuro` —no como variable sobre `.btn-close`— porque es lo ÚNICO de esta
   hoja que depende del tema y no del token: invertir la X en tema claro la dejaría blanca sobre
   blanco. */
.tema-oscuro .btn-close {
    filter: var(--bs-btn-close-white-filter);
}

/* ============================================================================================
 * 3. LOS CUATRO BADGES — Y UNA ADVERTENCIA QUE NO SE PUEDE TAPAR
 *
 * `.text-bg-*` es el reemplazo que Bootstrap 5 le da a `.badge-*` de Bootstrap 4, y AC6 obliga a
 * declararle `background-color` con el token de la familia. Se declara, porque es el contrato.
 *
 * PERO ESTAS CUATRO DECLARACIONES NO PINTAN, y queda escrito acá en vez de simularse: la 5.3.2
 * escribe `.text-bg-primary{…background-color:RGBA(var(--bs-primary-rgb),…)!important}`, y
 * `!important` le gana a una declaración normal sin importar el orden de enlace ni la
 * especificidad. La única vía que las haría pintar es pisar `--bs-primary-rgb`, que espera un
 * triplete y no un color (ver el límite declarado en la cabecera).
 *
 * O sea que para estas cuatro clases el contrato de AC6 ("declarar el token") y el de AC2 ("ningún
 * `!important` en toda la hoja") son satisfacibles a la vez sólo en el TEXTO, no en el efecto.
 * Está devuelto como pregunta al orquestador junto con las utilidades `.bg-*`/`.text-*`.
 * ============================================================================================ */

.text-bg-primary {
    background-color: var(--accent);
}

.text-bg-success {
    background-color: var(--success);
}

.text-bg-warning {
    background-color: var(--warning);
}

.text-bg-danger {
    background-color: var(--danger);
}

/* ============================================================================================
 * 4. EL FOCO DE LOS CONTROLES DE FORMULARIO — spec-20260915-002-lucayuvdev (AC1/AC4)
 *
 * LAS ÚNICAS DOS REGLAS DE ESTA HOJA QUE COPIAN UN SELECTOR DE BOOTSTRAP EN VEZ DE PISAR UNA
 * VARIABLE, Y ESTÁ MEDIDO POR QUÉ NO HABÍA OTRA FORMA.
 *
 *   Bootstrap 5.3.2 declara el foco de estos dos componentes con LITERALES sobre el selector del
 *   componente:
 *
 *     .form-control:focus{…border-color:#86b7fe;outline:0;box-shadow:0 0 0 .25rem rgba(13,110,253,.25)}
 *     .form-select:focus {border-color:#86b7fe;outline:0;box-shadow:0 0 0 .25rem rgba(13,110,253,.25)}
 *
 *   NINGUNA DE LAS DOS LEE `--bs-focus-ring-color`. Tokenizar esa variable —que es lo que el
 *   reconocimiento del defecto sugería— deja la hoja completa, correcta a la vista y SIN NINGÚN
 *   EFECTO: exactamente el modo de falla que la cabecera de este archivo ya nombra y que la
 *   unificación pagó una vez. Se tokeniza igual (§ 1), porque sí gobierna `:focus-visible` y
 *   `.focus-ring`, pero no es esto.
 *
 *   Lo que sí pinta es el gemelo real. Mismo desempate que el resto de la hoja: misma
 *   especificidad (0-2-0 contra 0-2-0) y esta hoja va DESPUÉS por orden de enlace. Mover su
 *   `<link>` una línea antes deja estas dos reglas sin efecto, igual que a todo lo demás.
 *
 * EL HALO SALE DE `--accent-halo` (§ 1) Y NO DE UNA MEZCLA ESCRITA ACÁ: la misma alfa la consume
 * también `--bs-focus-ring-color`, y escribirla dos veces sería la misma decisión duplicada (Q2).
 * El § 1 explica por qué ese token vive en esta hoja y no en la de tokens, y cómo degrada.
 *
 * `outline: 0` NO se repite: Bootstrap ya lo declara en su propia regla y no es color.
 *
 * ALCANCE: las dos reglas alcanzan a TODO control con `.form-control` o `.form-select` de la app,
 * incluido el `<input type="date">` de `RenderInputs` (case `Fecha`), que es `.form-control` y por
 * eso AC4 no necesita una tercera regla propia.
 * ============================================================================================ */

.form-control:focus,
.form-select:focus {
    border-color: var(--accent);
    box-shadow: 0 0 0 0.25rem var(--accent-halo);
}