/* ═══════════════════════════════════════
   ▓ COMPONENTE · Tabs — gemelo vanilla ▓
   v1.1 · 2026-09-20. Ficha: design-system/COMPONENTE_TABS.md
   Kit: catalogo-cd/components/Tabs.jsx

   LAS PESTAÑAS QUE ORDENAN EL CONTENIDO DE UN SUBMÓDULO, y son la MÁXIMA GRANULARIDAD
   DE ORDEN DEL SISTEMA (Ricardo, 2026-07-23): sidebar → topbar → TABS → y de ahí
   para abajo ya no es navegación, es layout de la pantalla.

   ⛔ EL DESLIZAMIENTO DE CONTENIDO (papel 8, COMPONENTE_MOVIMIENTO.md · Ricardo,
   2026-09-20) NO VIVE EN ESTA HOJA. Es coreografía por `transform`, calculada al vuelo
   con inline styles sobre los DOS nodos que el anfitrión decide (viejo/nuevo) — vive
   en `exdsTabs.deslizar()`, `tabs.js`. Aquí no hay nada que tokenizar porque no hay
   nada que declarar por selector: los paneles del anfitrión no son parte de ESTA
   pieza, sólo la barra y su indicador lo son.

   ⛔ EL INDICADOR ES UNA BARRA DE 2px DEBAJO DE LA ACTIVA. Nunca una caja, nunca una
   píldora — eso es un segmentado, que es otra pieza y significa otra cosa (elegir un
   modo, no cambiar de sección).

   ⛔ Y ES UN SOLO INDICADOR QUE SE DESLIZA, no un ::after por pestaña (Ricardo,
   2026-07-24). La diferencia no es estética: un ::after por pestaña SALTA —aparece
   apagándose aquí y encendiéndose allá— y el ojo pierde la relación entre las dos.
   Uno que viaja la conserva. Se mide la pestaña activa y el indicador va a su sitio;
   por eso esta pieza NECESITA su tabs.js.

   REQUISITOS DEL ANFITRIÓN:
     1. Los tokens del canon (colors_and_type.css).
     2. box-sizing: border-box.
     3. tabs.js — sin él el indicador no se coloca (no hay CSS que pueda medir un hijo).
     4. ⛔ QUE LA TIRA LLEGUE A LOS DOS BORDES DEL LIENZO. Esta pieza NO puede garantizarlo
        sola: un hijo no sabe cuánto relleno ni cuánto tope de ancho tienen sus ancestros.
        **Es un contrato del anfitrión**, y se escribe aquí porque el defecto ya se cobró dos
        veces el mismo día (2026-09-10, `DECISION-FUENTE: Ricardo — «la banda no cubre todo el
        ancho de la pantalla como si debería hacerlo»` y, al arreglarlo a medias,
        `«asegúrate de que este problema no ocurra y siempre cubra el ancho total»`).

        ⛔ Y LA TRAMPA ESTÁ EN QUE SON **DOS** COSAS, NO UNA — la primera vez se compensó sólo
        la primera y el defecto siguió vivo:
          (a) el **relleno lateral** del contenedor de la vista;
          (b) el **tope de ancho con centrado automático** (`max-width` + `margin:auto`). Éste
              es el que se olvida: no se ve en el CSS de la tira ni en el de su padre directo,
              y su margen **crece con la pantalla** — a 1920 px eran 200 px por lado.

        **Por eso la compensación NO puede ser un número fijo**: tiene que derivarse del ancho
        real del lienzo. En el backoffice de Exante es
        `max(0px, (anchoLienzo − tope) / 2)` sumado al relleno lateral, devuelto como relleno
        interno para que la primera pestaña siga alineada con la primera columna del contenido.

        **Cómo se comprueba, y no vale a ojo:** el `left` y el `right` de la tira deben coincidir
        con los del lienzo **en varios anchos** (1920, 1440, y uno por debajo del tope, donde la
        compensación debe dar cero) **y con el riel plegado**. *Una compensación que sólo se mide
        a un ancho acierta por casualidad: el margen de centrado es cero hasta que la pantalla
        pasa del tope.*
     5. ⛔ Y DENTRO DEL SHELL, ADEMÁS, LAS PESTAÑAS ARRANCAN EN EL MARGEN DEL CONTENIDO,
        NO EN EL BORDE DE LA BANDA (`DECISION-FUENTE: Ricardo, 2026-09-12`, ver la nota
        junto a `margin-left` más abajo). El anfitrión declara `--exds-content-inset-x` en
        el ancestro común de la tira y del contenido (`.exds-content`); esta pieza sangra
        la banda hacia afuera por esa misma medida y la devuelve como relleno interno.
        Sin la variable, `0px` — la pieza no cambia sola de aspecto en quien no la declara.
   ═══════════════════════════════════════ */

/* ── LA BARRA ────────────────────────────────────────────────────────────────
   (La declaración GATE-ALLOW de la box-shadow se retira con la sombra, 2026-09-10:
   una declaración que ampara un valor que ya no existe deja de declarar y pasa a
   confundir a quien la lea buscando por qué hay una excepción.)
   — histórico: box-shadow escrita a mano — era la elevación SUTIL de una barra pegajosa
   (despegarla del contenido que corre por debajo), no la caja de una tarjeta; la ficha la
   conserva tal cual desde el handoff (COMPONENTE_TABS.md / COMPONENTE_SHELL.md § invención 3). */
.exds-tabs {
  position: relative;
  z-index: 6;
  /* ⛔ LA BARRA LLEVA FONDO · 2026-09-10
     `DECISION-FUENTE: Ricardo, 2026-09-10 — «en producción coexisten dos diseños, uno con
     una especie de fondo blanco anclado arriba y otro sin fondo blanco anclado a pantalla
     lista. Lo correcto es con el fondo blanco».`
     ⛔ RETIRA «SIN FONDO» (2026-09-09), que vivía aquí. No se corrige porque estuviera mal
     escrita: se corrige porque él decidió distinto al día siguiente, con las dos formas
     vivas delante — el de Operación (`.op-tabsbar`, con fondo) y el de STP (esta pieza, sin
     él). El canon guarda la fecha de las dos, no discute la anterior.
     ⚠ Y LO QUE FALLÓ ERA JUSTO LO QUE ESTA HOJA HABÍA DECLARADO QUE FALLARÍA. La nota del
     09-09 decía, palabra por palabra: «la barra es sticky, y el fondo impedía que el
     contenido se viera por detrás al desplazarse; sin él, si alguna pantalla la fija, el
     contenido correrá visible bajo las pestañas — se declara aquí en vez de descubrirlo en
     una pantalla». *Un riesgo declarado y no vigilado se cobra igual que uno que nadie vio;
     lo único que cambia es que después se puede leer quién lo escribió.*
     La sombra NO vuelve: se retiró el mismo 09-09 por una decisión SUYA aparte («la línea
     que está bajo de las tabs no debería llevar esa sombra») y esa sigue en pie. El fondo y
     la sombra se sostenían mutuamente y por eso cayeron juntas — pero volver es de una sola:
     lo que la barra necesita es OPACIDAD para tapar lo que corre debajo, no elevación. */
  background: var(--color-surface, #FFFFFF);
  border-bottom: 1px solid var(--color-border-subtle, #E5E7EB);
  /* ⛔ SIN SOMBRA · 2026-09-09
     `DECISION-FUENTE: Ricardo, 2026-09-09 — «la línea que está bajo de las tabs no debería
     llevar esa sombra. Revisa el módulo de facturación para que te des una idea de cómo debe
     de ser».`
     Aquí había `box-shadow: 0 6px 14px -10px rgba(15,20,25,.18)`. La referencia que él nombra
     —`.exv3-dtabs` de Facturación (`admin/css/backoffice.css:6859`)— es **una línea de 1px y
     nada más**: sin fondo y sin sombra. Lo que separa la tira del contenido es esa línea.
     *La elevación estaba defendiendo a la barra de un contenido que corriera por debajo —
     el mismo trabajo que hacía el fondo retirado hoy—, y las dos se sostenían mutuamente:
     al caer una, la otra dejó de tener a quién proteger.* */
  flex-shrink: 0;
  display: flex;
  /* ⛔ SIN RELLENO LATERAL · 2026-09-09 — REDACCIÓN CORREGIDA EL 2026-09-12, se conserva
     con su fecha porque explica el gap y sigue siendo cierta para el caso que la motivó.
     `DECISION-FUENTE: Ricardo, 2026-09-09 — «Facturación tiene su subrayado del primer
     elemento de la tab anclado a la izquierda. En STP hay un espacio sobrante».`
     Aquí había `padding: 0 32px`, y la referencia —`.exv3-dtabs` de Facturación— no tiene
     ninguno: sus pestañas arrancan en el borde y el subrayado de la primera queda anclado a
     la izquierda, en la misma vertical que todo lo que va debajo.
     El `gap` sube de 4 a 18 (`--space-4-5`) por lo mismo: sin relleno en cada pestaña, la
     separación tiene que darla la tira — es el valor de la referencia.

     ⛔ LO QUE ESTA NOTA YA NO DICE, RETIRADO EL 2026-09-12: decía «el contenido arranca en
     el borde, no sangrado» como regla general. No lo es.
     `DECISION-FUENTE: Ricardo, 2026-09-12 — «no tiene margen, esta pegado directo al borde
     de barra lateral. underlined tabs deben tener margen también (…) ese margen depende al
     ancho designado del contenido».`
     Dentro del Shell (`.exds-content`), el contenido de la app SÍ lleva margen — 56px en
     `mi-exante`, 40px en el backoffice (medidos, y DISTINTOS entre sí) — y la tira tiene que
     arrancar en la MISMA vertical, no en el borde del lienzo. Ese valor no se escribe aquí:
     lo fija el anfitrión en `--exds-content-inset-x` (ver abajo).
     ⛔ FACTURACIÓN Y STP SÍ HEREDAN ESA VARIABLE (40px), Y NO ES EL `0px` DE RESERVA LO QUE LAS
     PROTEGE. Aquí decía que «no montan `.exds-content` y no declaran esa variable»: es FALSO, y
     lo midió `revisor-qa` el 2026-09-12 poniendo la variable en un valor absurdo y mirando quién
     obedecía — con `--exds-content-inset-x: 999px` las dos tiras se quedan en `-40px`, y sólo se
     mueven al tocar `--bo-content-pad-x`. Lo que las deja intactas es la ESPECIFICIDAD de su
     propia regla (`#stpTabs` / `.fx-tabs`, derivada de `--fx-bleed-gap`, en `admin/index.html`).
     El `0px` de reserva protege a los montajes sueltos, no a ellas.
     *La conclusión era correcta y su razón falsa — y eso importa porque la frase invitaba a
     retirar ese `GATE-ALLOW` por redundante: el día que se retire, las dos sangran 40px.*
     ⛔ Y la lección de método, que es la que sobrevive: **medir que algo NO se mueve no prueba
     POR QUÉ no se mueve.** Para saber qué regla manda se mueve la variable a un valor absurdo y
     se mira quién obedece. La nota del 09-09 sigue vigente para esas dos tiras. */
  gap: var(--space-4-5, 18px);
  padding: 0;
  /* ⛔ LA BANDA SANGRA, LAS PESTAÑAS NO · 2026-09-12 (mismo `DECISION-FUENTE` de arriba).
     Reutiliza el mecanismo que ya existe en producción para el mismo problema
     (`--fx-bleed-gap` de Finanzas, `exante-git/admin/index.html`): margen negativo hacia
     afuera + el mismo valor devuelto como relleno interno. Ahí la fórmula deriva de un
     tope de ancho centrado; aquí no hay tope — sólo el margen fijo del contenido — así que
     basta UNA variable, puesta por el anfitrión en el ancestro común de la tira y el
     contenido (`.exds-content`). Por defecto vale 0px: una pieza que NO declara la variable
     (Facturación, STP, cualquier montaje suelto de `.exds-tabs`) no cambia de comportamiento. */
  /* ⛔ Y LA SEGUNDA SANGRÍA · --exds-canvas-bleed-x · 2026-09-15
     `DECISION-FUENTE: Ricardo, 2026-09-15 — «D2: A» · «no solo lo registres como esta
     instancia. La banda SIEMPRE va así» · «Tanto mi exante como backoffice, en todos los
     modulos y submodulos».`
     La banda cruza DOS obstáculos, no uno, y hasta hoy esta hoja sólo compensaba el primero:
       (a) el RELLENO lateral de la vista → --exds-content-inset-x (arriba);
       (b) el TOPE DE ANCHO CENTRADO de la vista (`max-width` + `margin:auto`) → esta variable.
     (b) es el que se olvida: no aparece en el CSS de la tira ni en el de su padre directo, y su
     margen CRECE con la pantalla — vale 0 hasta que el lienzo pasa del tope, así que una
     compensación medida a un solo ancho acierta por casualidad. Ya se olvidó tres veces: dos en
     Finanzas › STP el 2026-09-10 y una en mi-exante el 2026-09-15 (banda 1180 sobre tarjeta
     1068, 56px sobresaliendo por lado y sin tocar ninguno de los dos bordes del lienzo).
     ⛔ POR QUÉ SIGUE SIENDO UNA VARIABLE DEL ANFITRIÓN y no la calcula esta pieza: dentro de un
     contenedor topado, `100%` YA es el ancho topado — un hijo no puede medir el lienzo que lo
     contiene. El valor es `max(0px, (anchoLienzo - tope) / 2)` y sólo lo sabe quien conoce las
     dos cifras. Producción ya tiene esa fórmula viva en Finanzas (`--fx-bleed-gap`,
     exante-git/admin/index.html): esto la sube al catálogo para que deje de ser un parche por
     módulo. Por defecto 0px — quien no la declara se pinta exactamente como antes. */
  margin-left: calc(-1 * (var(--exds-content-inset-x, 0px) + var(--exds-canvas-bleed-x, 0px)));
  margin-right: calc(-1 * (var(--exds-content-inset-x, 0px) + var(--exds-canvas-bleed-x, 0px)));
  padding-left: calc(var(--exds-content-inset-x, 0px) + var(--exds-canvas-bleed-x, 0px));
  padding-right: calc(var(--exds-content-inset-x, 0px) + var(--exds-canvas-bleed-x, 0px));
}

/* Pegada arriba de su contenedor con desplazamiento. Es el default: unas tabs que se
   van al hacer scroll dejan de ser navegación y pasan a ser un encabezado. */
.exds-tabs[data-sticky="true"] { position: sticky; top: 0; }

/* EXCEPCIÓN DECLARADA — pantallas de DETALLE (2026-09-17): la banda deja de ser la cabecera de
   la PANTALLA y pasa a ser la cabecera de UNA TARJETA (TarjetaPestanas, invento I-2).
   DECISION-FUENTE: Ricardo, 2026-09-17 — «3A». Ahí el hairline y el sangrado al lienzo NO
   aplican: los pinta el CONTENEDOR de la tarjeta (a todo el ancho de SU banda, ranura de acción
   incluida). COMPONENTE_TABS.md § LA BANDA SIEMPRE VA ASÍ documenta esta excepción con su
   porqué. Se declara en el consumidor (data-en-tarjeta="true"), igual que data-superficie
   ="oscura" — nunca se adivina del padre. */
.exds-tabs[data-en-tarjeta="true"] {
  border-bottom: none;
  margin-left: 0;
  margin-right: 0;
  padding-left: 0;
  padding-right: 0;
}

/* ── LA PESTAÑA ──────────────────────────────────────────────────────────────
   El margen derecho de 22 no es el gap: el gap separa las CAJAS y el margen separa
   los TEXTOS. La caja de una pestaña llega hasta donde llega su etiqueta —el
   indicador mide eso— así que la respiración va por dentro. */
.exds-tab {
  position: relative;
  display: flex;
  align-items: center;
  gap: 8px;
  padding: 15px 0;
  margin-right: 22px;
  border: none;
  background: transparent;
  cursor: pointer;
  font: 500 var(--fs-body, 14px) var(--font-sans);
  color: var(--fg3);
  transition: color var(--motion-fast) var(--ease-default);
}
/* ⛔ HOMOLOGADO 2026-09-08 · era `--fg4`, el token de DESACTIVADO — y una pestaña sin
   seleccionar NO lo está: se pulsa para cambiar de vista. `--fg4` es `#B8BDC7` = **1.88:1**,
   por debajo del 3:1 que WCAG 1.4.11 exige a un componente gráfico; lo deshabilitado está
   exento de ese umbral, lo inactivo-pero-pulsable no. Y el escalón tampoco cuadraba: el
   rótulo de `.exds-tab` va en `--fg3` (línea de arriba), así que el ícono estaba dos
   escalones por debajo de su propia palabra. Regla en `COMPONENTE_ICONO.md`, tabla de TINTA.
   ⛔ Y ESTE ES EL CASO GRAVE DE LOS CUATRO: vivía en el componente CANÓNICO, así que no era
   un despiste de una pantalla — era el catálogo repartiéndolo. *Un canon equivocado sale de
   fábrica con todos los medidores en verde* (`GOBIERNO.md` §0-ter). Lo cazó el medidor de
   tinta por contexto el día que se construyó; el barrido a ojo de esa misma mañana no lo vio. */
.exds-tab svg, .exds-tab .exds-tab-ico { color: var(--fg3); display: inline-flex; flex-shrink: 0; }
/* ⛔ MEDIDA DEL ÍCONO, AL CANON (2026-09-15) — vivía sólo en el marcado (`width="16"
   height="16"` en cada `<svg>`), y las 7 instancias vivas la repiten igual: Facturación
   Recibidas/Emitidas/Conciliación, Finanzas›STP Abonos/Cargos (atributo) y Notificaciones/
   Parámetros (donde el trazo sale de una fuente compartida sin medida propia, y hoy se
   sostiene con una regla local en la página anfitriona). Una medida que sólo vive en el
   marcado no sobrevive a la siguiente copia — se escribe aquí para que sea la fuente. */
.exds-tab-ico svg { width: 16px; height: 16px; }
.exds-tab:hover { color: var(--fg2); }
.exds-tab:focus-visible {
  outline: none;
  box-shadow: inset 0 0 0 1px var(--color-border-focus);
  border-radius: var(--radius-sm);
}
/* El anillo de foco sobre superficie oscura · el token neutro da 3,92:1 sobre el suelo
   #0F1419 y ya despejaria el 3:1 de un control, pero al lado de esta pestaña vive un
   boton del catalogo que desde el 2026-08-28 lo sube a tinta blanca (18,5:1). Dos
   controles hermanos, sobre la misma barra, con anillos distintos: eso no es una
   diferencia de matiz, es que uno de los dos parece apagado.
   Lo cazo la primera adopcion real de superficie oscura: la barra publica del cotizador.
   *Un hueco del catalogo no se ve hasta que alguien monta dos piezas suyas juntas.* */
.exds-tabs[data-superficie="oscura"] .exds-tab:focus-visible {
  box-shadow: inset 0 0 0 1px var(--color-ink-on-dark, #FFFFFF);
}

.exds-tab.is-active { font-weight: var(--fw-semibold, 600); color: var(--fg1); }
.exds-tab.is-active svg, .exds-tab.is-active .exds-tab-ico { color: var(--fg1); }

/* ── EL CONTADOR ─────────────────────────────────────────────────────────────
   Absorbido en la pestaña el 2026-08-23 (Ricardo, 2026-08-24: «absorber en las
   pestañas que ya existen»). NO es una segunda clase de pestaña: es la misma con un
   número al lado, y sin número se pinta EXACTAMENTE igual que antes.

   ⛔ TABULAR, y aquí duele el doble: sin eso el número pasa de 12 a 11, la pestaña se
   estrecha y MUEVE EL SUBRAYADO — que además se desliza midiendo la activa, así que
   se movería solo, sin que nadie tocara nada.
   ⛔ Y alinea por BASE, no por centro: un número más pequeño centrado con su etiqueta
   se lee flotando.
   ⛔ La base se alinea SÓLO en la pestaña que lleva contador, con :has(). Cambiar
   align-items en todas movería los íconos de las que no lo llevan — un cambio de
   aspecto que nadie pidió, y que además sería decisión de diseño. */
.exds-tab:has(.exds-tab-cuenta) { align-items: baseline; }
.exds-tab:has(.exds-tab-cuenta) svg,
.exds-tab:has(.exds-tab-cuenta) .exds-tab-ico { align-self: center; }
.exds-tab-cuenta {
  font-weight: var(--fw-medium,500);
  font-size: var(--fs-eyebrow,11px);
  font-variant-numeric: tabular-nums;
  letter-spacing: var(--tracking-eyebrow,0.12em);
  color: var(--fg4);
  transition: color var(--motion-fast) var(--ease-out);
}
[aria-selected="true"] .exds-tab-cuenta { color: var(--fg2); }
@media (prefers-reduced-motion:reduce) { .exds-tab-cuenta { transition: none; } }

/* ── EL INDICADOR QUE VIAJA ──────────────────────────────────────────────────
   `left` y `width` NO están aquí a propósito: los escribe tabs.js midiendo la pestaña
   activa. Ningún CSS puede medir un hijo, así que el sitio del indicador es el único
   valor de esta pieza que no puede vivir en la hoja. */
.exds-tab-thumb {
  position: absolute;
  bottom: -1px;
  height: 2px;
  border-radius: 2px 2px 0 0;
  background: var(--color-action-ink);
  transition: left var(--motion-base,250ms) var(--ease-default),
              width var(--motion-base,250ms) var(--ease-default);
}
@media (prefers-reduced-motion:reduce) { .exds-tab-thumb { transition: none; } }

/* ── LA PESTAÑA SOBRE SUPERFICIE OSCURA · LA PÍLDORA ───────────────────────────────
   DECISION-FUENTE: Ricardo, 2026-08-27 — decisión 2.2 de «LAS 19 DECISIONES DE LA
   HOMOLOGACIÓN» (ESTADO.md): «Píldora, y se escribe en el canon como el tratamiento de
   pestaña sobre superficie oscura».

   ⛔ NO SUSTITUYE A LA SUBRAYA: LA ACOMPAÑA, Y SU CONDICIÓN DE USO ES ÚNICA.
     · fondo claro  → subraya de 2px en tinta. Sigue siendo LA regla.
     · fondo oscuro → píldora. Y sólo ahí.
   La subraya del canon es tinta (--color-action-ink) y sobre negro es TINTA SOBRE TINTA:
   invisible. La pantalla no estaba mal — al canon le faltaba el caso. *Cuando el canon
   empeora la pantalla, no es que la pantalla se desvíe: es que el canon no ha visto ese suelo.*

   ⛔ Y SIGUE SIENDO UN SOLO INDICADOR QUE VIAJA (Ricardo, 2026-07-24). No se cambia el
   mecanismo, se cambia la piel del MISMO .exds-tab-thumb: de barra de 2px abajo a caja
   redonda detrás. Por eso tabs.js no cambia ni una línea — ya mide la pestaña activa.
   Un indicador por pestaña saltaría, y ese salto es justo lo que el deslizante vino a quitar.

   La condición se DECLARA en el contenedor (data-superficie="oscura"), no se adivina del
   color de fondo: ver COMPONENTE_SUPERFICIE_OSCURA.md.

   El relleno de 8px 20px sustituye al de 15px 4px porque una píldora envuelve la etiqueta y
   una subraya sólo la mide: el aire que en claro va POR FUERA (margin-right 22) aquí va POR
   DENTRO, o el fondo quedaría pegado al texto. */
.exds-tabs[data-superficie="oscura"] { background:var(--color-bg-dark, #0F1419); border-bottom:1px solid var(--color-hairline-dark, rgba(255, 255, 255, 0.08)); box-shadow:var(--shadow-none, none); gap:var(--space-0-5, 2px); }
.exds-tabs[data-superficie="oscura"] .exds-tab { padding:8px 20px; margin-right:0; border-radius:var(--radius-pill, 999px); color:var(--color-ink-on-dark-muted, #B8BDC7); z-index:1; }
.exds-tabs[data-superficie="oscura"] .exds-tab:hover, .exds-tabs[data-superficie="oscura"] .exds-tab.is-active { color:var(--color-ink-on-dark, #FFFFFF); }
.exds-tabs[data-superficie="oscura"] .exds-tab svg, .exds-tabs[data-superficie="oscura"] .exds-tab .exds-tab-ico { color:var(--color-ink-on-dark-hint, #8B92A1); }
.exds-tabs[data-superficie="oscura"] .exds-tab.is-active svg, .exds-tabs[data-superficie="oscura"] .exds-tab.is-active .exds-tab-ico { color:var(--color-ink-on-dark, #FFFFFF); }
.exds-tabs[data-superficie="oscura"] .exds-tab-cuenta { color:var(--color-ink-on-dark-hint, #8B92A1); }
.exds-tabs[data-superficie="oscura"] [aria-selected="true"] .exds-tab-cuenta { color:var(--color-ink-on-dark-muted, #B8BDC7); }
/* El alto NO se escribe: sale de arriba y abajo pegados a la barra, cuyo alto es el de la
   pestaña. Escribir 33 —el número que produccion tiene hoy— lo dejaría clavado el día que
   cambie el relleno, y nadie lo relacionaría. */
.exds-tabs[data-superficie="oscura"] .exds-tab-thumb { top:0; bottom:0; height:auto; border-radius:var(--radius-pill, 999px); background:var(--color-bg-subtle-on-dark, rgba(255, 255, 255, 0.10)); pointer-events:none; z-index:0; }