/* ==========================================================================
   NAVEGACIÓN (menú, patrón "Cabecera_452", TT5)
   ==========================================================================
   Contexto (11/08/2026): hasta esta fecha había DOS filas de cabecera
   completas (una para escritorio, otra para móvil), mostradas/ocultadas
   por CSS según el ancho de pantalla. Se simplificó a UN solo bloque
   Navigation, sacado de las columnas del logo/título y colocado como
   bloque propio debajo, con la clase CSS adicional "menu-principal-nuevo"
   puesta a mano desde el editor (bloque Menú → Avanzado → Clase CSS
   adicional). El propio bloque Navigation ya trae su comportamiento
   responsive nativo de WordPress: barra horizontal en línea a partir de
   600px, botón hamburguesa + panel superpuesto por debajo. Ese breakpoint
   lo fija el CSS que WordPress inyecta en el <head> (no editable desde
   aquí), así que este archivo no reinventa la visibilidad — solo viste
   los dos estados que WordPress ya construye.

   17-18/08/2026: todo el CSS que existía sobre la CABECERA en sí
   (".cabecera-logo-titulo" — fondo, márgenes, tamaños de letra, qué
   columnas se ocultaban según el ancho...) se ha retirado a petición
   expresa: el responsable del proyecto va a rediseñarla directamente
   desde el editor de bloques de Gutenberg, y ese CSS con !important le
   estaba "peleando" los cambios sin que se notara por qué. Lo que queda
   en este archivo es SOLO el MENÚ (nav.menu-principal-nuevo) — incluida
   la regla de aquí abajo, que sigue usando
   ".cabecera-logo-titulo ~ nav..." como referencia de posición (para
   distinguir el menú de Inicio, que vive como bloque propio justo
   debajo de la cabecera, del menú de la cabecera de Admin, que vive
   ANIDADO dentro de ella) — se mantiene porque solo afecta al MENÚ, no
   a la cabecera en sí. Si la cabecera cambia de clase o desaparece esa
   clase en el futuro, esta es la única regla que dejaría de aplicar y
   habría que revisar.
   ========================================================================== */

/* Excepción puntual sobre la cabecera (18/08/2026, a petición expresa):
   "VISTALEGRE 452" es un enlace, así que el navegador le pone su
   subrayado de enlace por defecto. El subrayado vive en el propio <a>
   interior, no en el <p class="titulo-sin-subrayado"> que lo envuelve —
   "text-decoration:none" en el párrafo no basta porque el <a> no tiene
   ninguna clase propia y el subrayado del navegador gana por estar
   declarado directamente sobre el elemento, no heredado. No es una
   vuelta atrás del resto (seguimos sin tocar fondo/márgenes/tamaños de
   la cabecera), es un ajuste suelto pedido expresamente. */
.cabecera-logo-titulo .titulo-sin-subrayado a {
    text-decoration: none !important;
}

/* Contorno suave (18/08/2026, a petición expresa): sin escudo y sin fondo
   de color, la cabecera se quedaba "flotando" sin ningún límite visual
   que la distinguiera del resto de la página. En vez de un fondo de
   color (que le devolvería peso, justo lo contrario de lo que se buscaba
   al quitar el morado sólido), se le da el mismo lenguaje de "tarjeta"
   que ya usa el resto del sitio (paneles, tablas...): borde fino gris +
   sombra suave, sin relleno. La cabecera se trata como pieza propia,
   independiente del menú de debajo (que se queda sin borde, tal cual
   está). */
.cabecera-logo-titulo {
    /* Borde aclarado (18/08/2026, a petición expresa: #AAAAAA → #D1D5DB,
       el mismo gris suave que ya se usa como borde de "utilidad" en el
       resto del sitio — var(--color-accion-borde-gris) en style.css). */
    box-shadow: 0 0 0 1px #D1D5DB;
    border-radius: var(--radio-tarjeta);
    /* Fondo blanco (18/08/2026, a petición expresa) — antes se probó
       transparente y el tono "papel" (#F7F1E2, el mismo de la caja de
       Agenda); se descartaron los dos. */
    background-color: #ffffff !important;
    /* Aire entre el borde de la tarjeta y su contenido (18/08/2026, a
       petición expresa). */
    padding-top: 20px;
    /* Aire entre el borde de la PANTALLA y el borde de la tarjeta (no lo
       mismo que el padding de arriba — esto es fuera de la tarjeta, no
       dentro). WordPress fuerza a 0 el margen superior del primer bloque
       de la página (":where(.is-layout-flow) > :first-child
       {margin-block-start:0}"), así que hace falta !important para
       ganarle. Usa la misma variable que el margin-bottom del menú y el
       margin-top del pie (--scout-ritmo-vertical, style.css) — los tres
       puntos del mismo ritmo vertical de plantilla, unificados el
       19/08/2026. */
    margin-top: var(--scout-ritmo-vertical) !important;
    /* "position:relative" (18/08/2026, a petición expresa: "que toda la
       cabecera sea un link a Inicio"): necesario como ancla para el
       enlace estirado de aquí abajo. */
    position: relative;
    cursor: pointer;
}

/* Enlace estirado (18/08/2026) — mismo criterio que ya se aplicó a las
   tarjetas del muro ese mismo día: en vez de envolver toda la cabecera en
   un <a> (aquí sería aún más problemático que en las tarjetas, porque
   "VISTALEGRE 452" ya es un enlace real y el HTML no permite anidar un
   <a> dentro de otro <a>), se estira el ÁREA DE CLIC del enlace que ya
   existe en el título hasta cubrir TODA la cabecera (".cabecera-logo-
   titulo", su ancestro con position:relative de arriba) con un ::after
   absoluto. El clic lo sigue recibiendo ese mismo <a>, así que no cambia
   ni su destino ni su semántica — solo su área sensible al toque/clic. */
.cabecera-logo-titulo .titulo-sin-subrayado a::after {
    content: '';
    position: absolute;
    inset: 0;
    z-index: 2;
}

/* Ocultar "SCOUTS | ASDE" en móvil, <780px (18/08/2026, a petición
   expresa) — Gutenberg no trae ningún ajuste nativo de "ocultar bajo tal
   ancho" para un bloque, así que se hace por CSS. Estructura actual (sin
   el escudo, que se quitó): .cabecera-logo-titulo tiene una única
   columna, que contiene el bloque de "Columnas" anidado con SCOUTS|ASDE
   seguido del párrafo "VISTALEGRE 452" — se oculta el primero por
   posición (es el único ".wp-block-columns" anidado ahí dentro). */
@media (max-width: 779px) {
    .cabecera-logo-titulo .wp-block-column > .wp-block-columns {
        display: none;
    }
    /* Con el bloque de arriba oculto, "VISTALEGRE 452" sigue siendo el
       SEGUNDO hijo a efectos del DOM, así que WordPress le sigue metiendo
       el margen automático de separación entre bloques
       (":where(.is-layout-flow) > *{margin-block-start:1.2rem}"), como si
       hubiera algo visible encima — se anula aquí. */
    .cabecera-logo-titulo .titulo-sin-subrayado {
        margin-block-start: 0 !important;
    }
}

/* nav.menu-principal-nuevo (con etiqueta) y no solo .menu-principal-nuevo:
   WordPress copia las clases del bloque también al <ul> interior
   (wp-block-navigation__container), así que una regla sin etiqueta se
   aplicaría dos veces — al <nav> exterior y al <ul> de dentro — y
   duplicaba visualmente el borde/sombra de separación (visto el
   11/08/2026: "línea doble"). */
.cabecera-logo-titulo ~ nav.menu-principal-nuevo {
    margin-left: auto;
    margin-right: auto;
    /* padding-top (18/08/2026, a petición expresa): aire entre el menú
       y lo que tenga encima (antes 0, quedaba todo pegado). */
    padding: 10px 12px 0;
    /* Sin esto, el padding de arriba se suma POR FUERA del ancho del
       bloque (comportamiento por defecto del navegador, box-sizing:
       content-box) y el <nav> acaba sobresaliendo por los lados. Bug
       real, visto el 11/08/2026 ("se sale la línea del menú"). */
    box-sizing: border-box;
    /* El menú es hijo de un bloque "Grupo" (is-layout-flow), así que
       WordPress le mete su margen automático de separación entre
       bloques (--wp--style--block-gap, la regla
       ":where(.is-layout-flow) > * { margin-block-start: 1.2rem }" del
       global-styles-inline-css) — de ahí una línea de hueco entre lo que
       hay encima y el menú. Se anula aquí porque el menú debe quedar
       pegado a lo de encima, sin ese hueco. */
    margin-block-start: 0;
    /* La línea gris fina que llevaba el borde superior se quitó el
       18/08/2026 a petición expresa (ya no hace falta para separar el
       menú de la cabecera, ahora ambos son claros/transparentes). */
    border-radius: 0 0 var(--radio-tarjeta) var(--radio-tarjeta);
    /* Separación respecto al contenido de la página (14/08/2026): este
       hueco nunca fue automático de verdad — dependía del margen
       automático nativo de WordPress entre bloques
       (--wp--style--block-gap), que dejó de aplicarse igual al añadir
       theme.json. Se fija aquí a mano, con --scout-ritmo-vertical
       (style.css) — la MISMA variable que usa el margin-top de la
       cabecera y el margin-top del pie, para no depender de ese mecanismo
       implícito. Esta es la ÚNICA fuente del hueco "menú → contenido" en
       todo el sitio: ningún contenedor de página (.scout-formulario-
       wrapper, cajas de aviso de shortcode-calendario.php...) debe poner
       su propio margin-top para separarse del menú, o el hueco se
       duplica (bug real, corregido el 19/08/2026 en varias páginas). */
    margin-bottom: var(--scout-ritmo-vertical);
}

/* El hueco entre el menú y el contenido (el margin-bottom de arriba)
   solo se veía correcto en Inicio — en el resto de páginas (ej.
   /contacto-directorio-de-grupo/, /tienda/) el bloque de CONTENIDO
   (hermano del bloque de cabecera a nivel de .wp-site-blocks, no del
   <nav>) traía SU PROPIO margen superior automático de WordPress
   (":where(.wp-site-blocks) > * {margin-block-start:1.2rem}", ≈19.2px)
   sin anular, así que se SUMABA al margin-bottom del menú en vez de
   fundirse con él — 39px en vez de 20px.
   Corrección real (18/08/2026): el primer intento de arreglar esto
   apuntaba mal — ".cabecera-logo-titulo ~ nav.menu-principal-nuevo + *"
   solo alcanza a los HERMANOS de <nav> DENTRO del propio patrón de
   cabecera (un <p> vacío que WordPress deja ahí, sin efecto visible
   real, porque ese <p> ya tenía margin-top:0 de por sí — el hueco de
   20px que "parecía" venir de él en realidad era el margin-bottom del
   propio <nav>). Nunca llegaba a tocar el bloque de contenido de verdad,
   que vive en el nivel de arriba (hermano del bloque de cabecera
   completo, no de <nav>). Se detectó que en Inicio el bloque de
   contenido no sufre esto porque tiene un style="margin-top:0" puesto A
   MANO en el editor de bloques (probablemente al tocar "Dimensiones" en
   algún momento) — un ajuste que nunca se replicó en el resto de
   plantillas. La regla de abajo usa :has() para enganchar al hermano
   real del bloque de cabecera (identificado por contener
   .cabecera-logo-titulo, sin importar la clase que traiga el bloque de
   contenido en cada plantilla — cambia según la plantilla: is-layout-
   constrained en Inicio, la "tarjeta" con borde en Tienda, etc.), así
   que ya no depende de poner ese ajuste a mano plantilla por plantilla. */
.wp-site-blocks > :has(.cabecera-logo-titulo) + * {
    margin-block-start: 0 !important;
}

/* ==========================================================================
   PIE DE PÁGINA (.pie-pagina-452) — 12/08/2026, a petición expresa: la
   misma idea de "tarjeta" (ancho de 1100px, esquinas redondeadas, sombra,
   separación del resto de la página) que tenía la cabecera — sin relación
   de código entre ambas, cada una con su propia clase. El pie es una
   parte de plantilla compartida por todo el sitio (Editor del sitio →
   Partes de plantilla), así que esta única clase basta para que quede
   así en todas las páginas. Solo se toca el envoltorio — el contenido
   (texto, color de fondo) no se toca, tal como se pidió. */
.pie-pagina-452 {
    /* width:100% (18/08/2026, a petición expresa): sin esto, el bloque se
       ajustaba al ancho de su propio contenido (el texto del copyright)
       en vez de estirarse hasta el max-width — por eso el recuadro se
       veía más estrecho o más ancho según cuánto ocupara el texto con la
       fuente en uso, en vez de medir siempre lo mismo que la cabecera. */
    width: 100%;
    max-width: 1100px;
    margin-left: auto;
    margin-right: auto;
    /* !important (20/08/2026, corrección real: comprobado en vivo que
       llegaba a pantalla con 0px de margen inferior real pese a este
       "24px" — WordPress pone su propia regla de margen automático entre
       los bloques directos de ".wp-site-blocks" ("margin-block-end: 0" en
       el último hijo), que sin "!important" le ganaba a este margen sin
       avisar. Mismo motivo exacto por el que "margin-top" de aquí abajo
       YA llevaba "!important" desde el 12/08/2026 — se quedó sin aplicar
       aquí por descuido en aquel momento). Subido a 40px de paso, a
       petición expresa ("dale un poco de aire al pie de página contra el
       borde inferior de la pantalla"). */
    margin-bottom: 40px !important;
    /* Misma variable que la cabecera y el menú (--scout-ritmo-vertical,
       style.css), unificada el 19/08/2026. */
    margin-top: var(--scout-ritmo-vertical) !important;
    border-radius: var(--radio-tarjeta);
    /* Contorno fino en vez de sombra difuminada (18/08/2026, a petición
       expresa) — mismo tratamiento que la cabecera ahora
       (.cabecera-logo-titulo, más arriba), para que hagan pareja de
       verdad. */
    box-shadow: 0 0 0 1px #D1D5DB;
    /* Recorta el fondo del párrafo de dentro a las esquinas redondeadas
       (el párrafo, no el grupo, es quien lleva el color de fondo). */
    overflow: hidden;
}
.pie-pagina-452 p {
    margin: 0;
    padding: 16px 20px;
}

.menu-principal-nuevo .wp-block-navigation__container {
    row-gap: 4px;
    gap: 4px;
}

/* ==========================================================================
   1. BARRA HORIZONTAL (≥600px) — el menú ya NO lleva fondo propio, es
      transparente a propósito (17-18/08/2026, a petición expresa, junto
      con la cabecera nueva) — de ahí que el texto se vista en el morado
      corporativo en vez de en blanco (blanco tenía sentido sobre un
      fondo morado sólido; sobre transparente/claro era invisible, visto
      en vivo el 18/08/2026: "El Grupo"/"Tienda"/"ADMIN" no se distinguían).
   ========================================================================== */
@media (min-width: 600px) {
    .menu-principal-nuevo .wp-block-navigation__container {
        flex-wrap: wrap;
    }

    /* El botón "Acceder"/"Salir" es HERMANO de la lista de ítems (no va
       dentro de ella), ambos dentro de este contenedor flex común — el
       alineado a la derecha va aquí, en el padre de los dos, para que se
       muevan juntos como un solo grupo. Ya no hace falta acotar aquí un
       ancho máximo propio (como en una versión anterior, cuando el <nav>
       todavía era una barra a sangre e intentaba imitar el ancho de la
       columna del muro): el ancho del <nav> lo fija su propio bloque
       desde el Editor del sitio (ver la regla
       ".cabecera-logo-titulo ~ nav.menu-principal-nuevo" más arriba), así
       que este contenedor ya vive dentro de esa anchura sin trucos extra. */
    .menu-principal-nuevo .wp-block-navigation__responsive-container-content {
        /* Alineado a la derecha (en vez del "centrado" del bloque) para
           que "Salir" toque el borde derecho de la tarjeta. */
        justify-content: flex-end;
    }

    .menu-principal-nuevo .wp-block-navigation-item__content {
        padding: 4px 10px !important;
        border-radius: var(--radio-boton);
        color: var(--scout-global-base) !important;
        font-weight: 600;
        font-size: 1rem;
        white-space: nowrap;
        transition: var(--transicion-suave);
    }

    /* Resaltado al pasar el ratón: antes un blanco translúcido (pensado
       para oscurecer un fondo morado sólido), ahora el mismo morado muy
       clarito que ya se usa para "fondo suave" en el resto del sitio
       (--scout-global-fondo), ya que el fondo real ahora es claro/
       transparente. */
    .menu-principal-nuevo .wp-block-navigation-item__content:hover,
    .menu-principal-nuevo .wp-block-navigation-item__content:focus {
        background-color: var(--scout-global-fondo);
        color: var(--scout-global-base) !important;
    }

    /* Página actual: mismo morado suave que el resaltado al pasar el
       ratón (18/08/2026, a petición expresa) — antes una pastilla
       blanca, que desentonaba ahora que el fondo del menú ya no es un
       morado sólido detrás. */
    .menu-principal-nuevo .current-menu-item > .wp-block-navigation-item__content,
    .menu-principal-nuevo .current-menu-ancestor > .wp-block-navigation-item__content {
        background-color: var(--scout-global-fondo);
        color: var(--scout-global-base) !important;
    }
    .menu-principal-nuevo .current-menu-item .wp-block-navigation__submenu-icon svg,
    .menu-principal-nuevo .current-menu-ancestor .wp-block-navigation__submenu-icon svg {
        stroke: var(--scout-global-base);
    }

    .menu-principal-nuevo .wp-block-navigation__submenu-icon {
        margin-left: 2px;
    }
    .menu-principal-nuevo .wp-block-navigation__submenu-icon svg {
        stroke: var(--scout-global-base);
    }

    /* Submenú desplegable: tarjeta blanca con sombra en vez del cuadro plano de WP */
    .menu-principal-nuevo .wp-block-navigation__submenu-container {
        background-color: #ffffff !important;
        border: none !important;
        border-radius: var(--radio-aviso);
        box-shadow: var(--sombra-hover);
        padding: 6px;
        min-width: 220px;
    }
    /* Gris neutro en vez de --scout-global-texto (18/08/2026, a petición
       expresa: "suavizar el negro") — esa variable es un morado mezclado
       con 80% de negro, muy oscuro casi como el negro puro; aquí se usa
       un gris suave en su lugar, sin tocar la variable compartida (la
       usan más sitios de la web que sí quieren ese tono oscuro). */
    .menu-principal-nuevo .wp-block-navigation__submenu-container .wp-block-navigation-item__content {
        padding: 10px 12px !important;
        border-radius: var(--radio-boton);
        color: #6b7280 !important;
    }
    .menu-principal-nuevo .wp-block-navigation__submenu-container .wp-block-navigation-item__content:hover {
        background-color: var(--scout-global-fondo);
        color: var(--scout-global-base) !important;
    }

    /* Submenús ANIDADOS (segundo nivel, ej. dentro de "ADMIN"): por
       defecto WordPress los abre en flyout hacia la DERECHA del padre,
       sin comprobar si hay sitio — con el padre cerca del borde derecho
       (habitual, suele ser de los últimos grupos del menú), el hijo se
       salía de la pantalla en apaisado/tablet, dejando hueco arrastrable
       (encontrado el 16/08/2026 en un móvil real). WordPress tiene una
       corrección nativa para esto, pero solo se activa con su propio
       ajuste de "justificación a la derecha" del bloque — no lo usamos,
       alineamos a la derecha con CSS propio (ver más arriba,
       ".wp-block-navigation__responsive-container-content"), así que esa
       lógica nunca se dispara. Se fuerza aquí en su lugar: abre hacia
       ABAJO del propio ítem (como un desplegable normal, no un flyout
       lateral) y hacia la IZQUIERDA (alineado por el borde derecho, en
       vez de por el izquierdo) — a petición expresa. */
    .menu-principal-nuevo .wp-block-navigation__submenu-container .wp-block-navigation__submenu-container {
        position: absolute !important;
        top: 100% !important;
        left: auto !important;
        right: 0 !important;
    }

    /* Lo de arriba no bastaba por sí solo (comprobado en vivo el
       16/08/2026): el PRIMER nivel de "ADMIN" (el desplegable que se abre
       al pulsar el propio "ADMIN", no el anidado de dentro) también se
       sale hacia la derecha por su cuenta — y como el anidado se
       posiciona relativo a ESE contenedor ya desplazado, heredaba el
       mismo problema un nivel más arriba, así que arreglar solo el
       anidado no bastaba. Se aplica el mismo giro aquí, pero solo al
       ítem de primer nivel que sea el ÚLTIMO del menú (":last-child",
       igual criterio que usa la propia lógica nativa de WordPress) — así
       "El Grupo" y el resto de ítems más a la izquierda, que si tienen
       sitio de sobra a la derecha, no cambian de comportamiento. */
    .menu-principal-nuevo .wp-block-navigation__container > .wp-block-navigation-item.has-child:last-child > .wp-block-navigation__submenu-container {
        left: auto !important;
        right: 0 !important;
    }

    /* Botón "Acceder"/"Salir": mismo estilo que cualquier otro ítem, sin
       contorno ni relleno propio, para que no destaque como algo aparte */
    .menu-principal-nuevo .wp-block-loginout a {
        display: inline-block;
        margin-left: 10px;
        padding: 8px 14px;
        border-radius: var(--radio-boton);
        background-color: transparent;
        color: var(--scout-global-base) !important;
        font-weight: 600;
        font-size: 0.95rem;
        text-decoration: none;
        white-space: nowrap;
        transition: var(--transicion-suave);
    }
    .menu-principal-nuevo .wp-block-loginout a:hover {
        background-color: var(--scout-global-fondo);
    }
}

/* ==========================================================================
   2. HAMBURGUESA Y PANEL (<600px) — envuelto a propósito en su propio
      @media (a diferencia de la sección 1, que solo depende de que
      WordPress oculte/muestre estos elementos por su cuenta): el
      contenedor `.wp-block-navigation__responsive-dialog` EXISTE en el
      DOM en todos los anchos, WordPress solo cambia cómo se posiciona su
      contenedor exterior (`position:relative` ≥600px). Poner aquí
      `position:absolute` sin @media (como se hizo en una versión anterior
      de este archivo) lo saca del flujo y lo encaja en una cajita de
      340px en la esquina también en escritorio — bug real, visto el
      11/08/2026 nada más publicar esta sección la primera vez. Por eso
      todo lo de este bloque va condicionado a <600px explícitamente,
      salvo el botón hamburguesa (ese si lo esconde WordPress por su
      cuenta a partir de 600px, sin necesidad de @media aquí). */

/* Botón hamburguesa: objetivo táctil cómodo (mínimo 44px). Fondo/icono en
   morado clarito/sólido (17-18/08/2026): antes un blanco translúcido
   sobre la barra morada sólida de antes, ahora la barra es transparente,
   así que ese mismo blanco quedaba invisible. */
.menu-principal-nuevo .wp-block-navigation__responsive-container-open {
    width: 44px;
    height: 44px;
    align-items: center;
    justify-content: center;
    border-radius: 50%;
    background-color: var(--scout-global-fondo);
    transition: var(--transicion-suave);
}
.menu-principal-nuevo .wp-block-navigation__responsive-container-open:hover,
.menu-principal-nuevo .wp-block-navigation__responsive-container-open:focus {
    background-color: var(--scout-global-borde);
}
.menu-principal-nuevo .wp-block-navigation__responsive-container-open svg path {
    fill: var(--scout-global-base);
}

@media (max-width: 599px) {
    /* Botón hamburguesa "atascado" al hacer scroll — v2 (18/08/2026,
       corrección a petición expresa): la v1 lo dejaba "position:fixed"
       SIEMPRE, así que aparecía superpuesto al título nada más cargar la
       página en vez de en su sitio habitual bajo la cabecera. La idea real
       era imitar un "position:sticky": en su sitio normal al cargar, y
       solo "pegado" al borde superior de la ventana una vez el scroll lo
       deja atrás — para eso hace falta saber CUÁNDO ha pasado eso, y con
       CSS puro no basta (ver más abajo).
       Reserva de altura mínima en el propio <nav>: cuando el JS active el
       estado "pegado" (ver clase más abajo), el botón sale del flujo
       normal y el <nav> se quedaría sin contenido que le dé altura propia
       — sin esto, el resto de la cabecera "saltaría" hacia arriba al
       activarse. Con la altura reservada aquí SIEMPRE (esté pegado o no),
       el cambio de estado no mueve nada más a su alrededor. */
    .menu-principal-nuevo {
        min-height: 54px;
    }

    .menu-principal-nuevo .wp-block-navigation__responsive-container-open {
        position: relative;
    }

    /* Estado "pegado": esta clase la añade/quita
       js/menu-hamburguesa-fija.js, no CSS puro — se necesitó JS porque
       "position:sticky" en el propio botón queda acotado a los límites de
       SU ELEMENTO PADRE (aquí, el <nav>, de solo ~54px de alto): en cuanto
       ese padre sale de la pantalla —casi enseguida, por lo bajo que es—
       el navegador lo "libera" y deja de pegarse, mucho antes de terminar
       de bajar por una página larga (comprobado en vivo el 18/08/2026).
       El script decide el momento exacto observando cuándo el propio
       <nav> deja de ser visible por arriba, y a partir de ahí esta clase
       controla el aspecto en modo fijo — mismo centrado y sombra que
       llevaba la v1, ahora solo activos cuando corresponde. */
    .menu-principal-nuevo.menu-hamburguesa-fija .wp-block-navigation__responsive-container-open {
        position: fixed;
        top: 12px;
        left: 50%;
        transform: translateX(-50%);
        z-index: 99999;
        box-shadow: var(--sombra-hover);
    }
}

@media (max-width: 599px) {
    /* Panel abierto: fondo oscuro de fondo + tarjeta blanca deslizante desde la derecha.
       "!important" en el fondo (18/08/2026): WordPress trae su propia regla de
       fábrica para el "overlay por defecto" del panel móvil
       (".wp-block-navigation:not(.has-background)
       .wp-block-navigation__responsive-container.is-menu-open:not(.disable-default-overlay)
       {background-color:#fff}"), con MÁS especificidad que esta (5 clases
       encadenadas vs 3) y sin !important propio — sin igualarla aquí, esa
       regla ganaba y pintaba el panel de blanco sólido, tapando la página de
       detrás en vez de oscurecerla (visto el 18/08/2026: "el contenido de la
       página desaparece del fondo"). */
    .menu-principal-nuevo .wp-block-navigation__responsive-container.has-modal-open {
        position: fixed;
        inset: 0;
        z-index: 999999;
        background-color: rgba(20, 10, 30, 0.55) !important;
    }

    /* WordPress solo le pone "width:100%" a este contenedor intermedio
       (".wp-block-navigation__responsive-close"), sin height. Sin
       "height:100%" aquí, el "height:100%" del panel de abajo no tiene
       contra qué resolverse (un % de altura no funciona sobre un padre
       de altura "auto") y el panel se encoge a la altura de su
       contenido en vez de ocupar toda la pantalla — bug real, visto el
       12/08/2026: el panel no llegaba abajo del todo y el aspa de cerrar
       quedaba flotando fuera de sitio.
       "display:flex" + centrado (18/08/2026, a petición expresa): antes el
       panel se anclaba a la derecha (position:absolute;top:0;right:0) —
       correcto cuando el botón hamburguesa estaba también a la derecha,
       pero ahora que la cabecera está centrada (botón hamburguesa en el
       centro), un panel anclado a la derecha quedaba descentrado respecto
       a lo que lo abre. Centrar aquí (el contenedor a pantalla completa)
       en vez de en el propio diálogo, para no tener que tocar su
       "position". */
    .menu-principal-nuevo .wp-block-navigation__responsive-close {
        height: 100%;
        display: flex;
        align-items: center;
        justify-content: center;
    }

    /* "position:relative" en vez de "absolute;top:0;right:0" (18/08/2026):
       con el padre ahora centrando por flex, el diálogo solo necesita
       fluir dentro de esa caja centrada — ya no necesita anclarse él mismo
       a una esquina. "max-height" en vez de "height:100%" fijo: como
       diálogo centrado (ya no ficha lateral a sangre completa), debe poder
       quedarse más corto que la pantalla si el contenido no llena, y aun
       así no desbordar en pantallas bajas. Esquinas redondeadas en los
       4 lados (--radio-tarjeta, igual que el resto de "tarjetas" del
       sitio) porque ahora se ven todos los bordes, no solo el izquierdo
       como en el panel lateral anterior. */
    .menu-principal-nuevo .wp-block-navigation__responsive-dialog {
        position: relative;
        width: min(82vw, 340px);
        max-height: 85vh;
        background-color: #ffffff;
        box-shadow: var(--sombra-hover);
        padding: 20px 18px;
        box-sizing: border-box;
        overflow-y: auto;
        border-radius: var(--radio-tarjeta);
    }

    /* Botón cerrar: círculo claro, fácil de encontrar y de pulsar */
    .menu-principal-nuevo .wp-block-navigation__responsive-container-close {
        width: 40px;
        height: 40px;
        align-self: flex-end;
        display: flex;
        align-items: center;
        justify-content: center;
        border-radius: 50%;
        background-color: var(--scout-global-fondo);
        margin-bottom: 10px;
    }
    .menu-principal-nuevo .wp-block-navigation__responsive-container-close svg path {
        fill: var(--scout-global-base);
    }

    /* Orden vertical dentro del panel: se usan las variables CSS que el propio
       bloque Navigation ya lee internamente (--navigation-layout-*) en vez de
       reescribir a mano el display/flex-direction — WordPress trae sus propias
       reglas de alta especificidad para esto y pelear contra ellas a mano es
       frágil. */
    .menu-principal-nuevo .wp-block-navigation__responsive-container {
        --navigation-layout-direction: column;
        --navigation-layout-justify: flex-start;
        --navigation-layout-align: stretch;
        --navigation-layout-wrap: nowrap;
        --navigation-layout-justification-setting: stretch;
    }

    /* ACORDEÓN (12/08/2026): por defecto WordPress mantiene todos los
       submenús del overlay móvil permanentemente visibles — su propia
       regla de fábrica (".is-menu-open ... .has-child .submenu-container
       {opacity:1;height:auto;visibility:visible}") tiene más
       especificidad que un selector "normal", así que hace falta
       igualarla o superarla a propósito aquí para poder colapsarlos.
       El botón de la flechita (antes oculto con display:none) ya trae
       de fábrica su propio mecanismo de abrir/cerrar cada submenú
       (atributo aria-expanded, gestionado por el propio WordPress) — no
       hace falta JS propio, solo devolverle el control visual. */
    .menu-principal-nuevo .wp-block-navigation__responsive-container .wp-block-navigation__responsive-container-content .has-child .wp-block-navigation__submenu-container {
        opacity: 0;
        height: 0;
        overflow: hidden;
        visibility: hidden;
        margin: 0 !important;
        padding-top: 0 !important;
        padding-bottom: 0 !important;
        transition: opacity 0.15s ease;
    }
    .menu-principal-nuevo .wp-block-navigation__responsive-container .wp-block-navigation__responsive-container-content .has-child > .wp-block-navigation-submenu__toggle[aria-expanded="true"] ~ .wp-block-navigation__submenu-container {
        opacity: 1;
        height: auto;
        overflow: visible;
        visibility: visible;
    }

    /* Fila de cada ítem con submenú: toda la fila abre/cierra el
       submenú, no solo el círculo de la flechita (visto el 12/08/2026:
       acertar en un círculo pequeño era poco fiable). La flechita se
       queda como INDICADOR VISUAL, pero deja de ser el único punto que
       responde al toque.

       Técnica: el enlace de texto pasa a "pointer-events:none" (dentro
       de esta vista únicamente) para que el toque lo atraviese, y el
       botón de la flechita se estira a toda la fila
       (position:absolute;inset:0) para recibirlo — sin ocultar
       visualmente el texto (el botón no lleva fondo propio salvo el
       resaltado sutil de "abierto"). Un primer intento (mismo día) puso
       el botón encima sin tocar el enlace y no funcionó (ver commits);
       esta vez el enlace deja de interceptar el toque en vez de
       competir con el botón por él. */
    .menu-principal-nuevo .wp-block-navigation__responsive-container .wp-block-navigation-item.has-child {
        display: flex;
        align-items: center;
        position: relative;
    }
    .menu-principal-nuevo .wp-block-navigation__responsive-container .wp-block-navigation-item.has-child > .wp-block-navigation-item__content {
        flex: 1 1 auto;
        min-width: 0;
        pointer-events: none;
        /* "pointer-events:none" en teoría basta para que el toque
           atraviese hasta el botón de abajo, pero en la práctica algunos
           móviles reales (confirmado el 16/08/2026) seleccionan el texto
           al tocarlo en vez de dejar pasar el toque del todo — estas
           opciones padre no llevan a ninguna página propia (van a "#",
           su única función es abrir el submenú), así que no tiene sentido
           que su texto sea seleccionable de todas formas. */
        -webkit-user-select: none;
        user-select: none;
    }
    /* "top/left/right + height" fija, en vez de "inset:0": el botón es
       hermano del propio contenedor del submenú DENTRO del mismo <li>, así
       que "inset:0" no cubre solo la fila de texto — cubre TODO el <li>,
       incluido el submenú ya desplegado debajo, y la flechita terminaba
       centrada en medio de ambos en vez de pegada arriba (visto el
       12/08/2026). Con una altura fija, igual a la de la fila de texto, se
       queda arriba pase lo que pase debajo. */
    .menu-principal-nuevo .wp-block-navigation__responsive-container .wp-block-navigation-submenu__toggle {
        position: absolute !important;
        top: 0 !important;
        left: 0 !important;
        right: 0 !important;
        height: 48px !important;
        display: flex !important;
        align-items: center !important;
        justify-content: flex-end !important;
        width: auto !important;
        padding-right: 14px !important;
        border-radius: var(--radio-boton);
        background-color: transparent;
        transition: var(--transicion-suave);
    }
    /* El icono usa el mismo color que el texto de su fila (--item-color:
       blanco en el padre morado, morado en los hijos de fondo blanco) —
       no un blanco fijo, porque sobre fondo blanco sería invisible. Un
       poco más grande que el tamaño de fábrica para que se note bien;
       "!important" también en el tamaño del SVG, mismo motivo de arriba. */
    .menu-principal-nuevo .wp-block-navigation__responsive-container .wp-block-navigation-submenu__toggle svg {
        width: 20px !important;
        height: 20px !important;
        stroke: var(--item-color, var(--scout-global-texto)) !important;
    }
    /* El navegador dibuja su propio recuadro de foco al tocar el botón —
       ":focus-visible" en vez de ":focus" a propósito: ":focus" se queda
       pegado también al tocar con el dedo (por eso quedaba un "marco"
       raro en la sección recién abierta, visto el 12/08/2026), mientras
       que ":focus-visible" solo se activa navegando con teclado, que es
       el único caso en que hace falta un indicador así. */
    .menu-principal-nuevo .wp-block-navigation__responsive-container .wp-block-navigation-submenu__toggle:focus {
        outline: none;
    }
    .menu-principal-nuevo .wp-block-navigation__responsive-container .wp-block-navigation-submenu__toggle:focus-visible {
        box-shadow: inset 0 0 0 2px var(--item-color, var(--scout-global-texto));
    }

    /* El color de texto de cada ítem se lee de la variable --item-color
       (con --scout-global-texto de reserva si nadie la redefine) en vez
       de pelear con varias reglas "color: ... !important" sueltas
       apuntando al mismo ítem — esa pelea de especificidades fue la
       causa real de que "El Grupo" y compañía desaparecieran del todo
       (texto invisible) al añadir el color por nivel, visto el
       12/08/2026. Con una sola variable, quien la redefine con más
       especificidad (más abajo, por nivel) gana sin ambigüedad, y aquí
       solo hay UNA declaración de "color" en todo el archivo para este
       elemento. */
    .menu-principal-nuevo .wp-block-navigation__responsive-container .wp-block-navigation-item__content {
        display: block;
        padding: 12px 10px !important;
        color: var(--item-color, var(--scout-global-texto)) !important;
        font-weight: 600;
        font-size: 1.05rem;
        background-color: transparent !important;
        border-radius: var(--radio-boton);
        text-align: center;
    }
    /* WordPress mueve el foco automáticamente al primer ítem ("Inicio")
       nada más abrir el panel (accesibilidad) — con ":focus" a secas ese
       fondo salía también con el enfoque automático al abrir el panel,
       no solo navegando con teclado, y "Inicio" se veía pálido/distinto
       al resto sin que se tocara (visto el 12/08/2026) — mismo arreglo
       que con la flechita: ":focus-visible" en vez de ":focus", para que
       solo se note con teclado real. */
    .menu-principal-nuevo .wp-block-navigation__responsive-container .wp-block-navigation-item__content:focus {
        outline: none;
    }
    .menu-principal-nuevo .wp-block-navigation__responsive-container .wp-block-navigation-item__content:focus-visible {
        background-color: var(--scout-global-fondo) !important;
    }
    /* --------------------------------------------------------------------
       COLOR "PADRE MORADO / HIJOS BLANCOS" (12/08/2026) → ALIGERADO
       (18/08/2026, a petición expresa: "quitarle peso a los botones, como
       en el estilo del resto de la web"). El morado SÓLIDO de fábrica se
       sustituye por el mismo lenguaje "outline" suave que ya usa el resto
       del sitio (fondo claro + borde/texto de color, ver
       "Colores de botones — convención estándar" en CLAUDE.md) — el
       nivel 1 pasa a tener el mismo peso visual que el nivel 2 (que ya
       era claro desde el principio), diferenciándose solo por un tono de
       fondo algo más marcado, no por un bloque sólido.

       "!important" en los fondos por el mismo motivo de siempre: WordPress
       fuerza ".wp-block-navigation-item{background:transparent!important}"
       dentro del overlay móvil (ver trampa #10 de CLAUDE.md) — sin
       igualarlo el fondo no se aplica y el texto queda invisible.
       -------------------------------------------------------------------- */

    /* El contenedor de submenú pasa a ser blanco (como el desplegable de
       escritorio) en vez de transparente — con fondo transparente se veía
       el morado del padre por detrás, muy parecido al morado del propio
       botón padre, y parecían "dos morados casi iguales" en vez de un
       único color con intención (visto el 12/08/2026). El aire lateral se
       hace con "padding" (no "margin" como en el intento anterior, que no
       se notaba lo suficiente) — el padding sí obliga a las cajas de
       dentro a quedar separadas del borde, pase lo que pase con el resto
       del layout flex. */
    /* Sin margen inferior propio (18/08/2026, a petición expresa: "demasiado
       aire abajo en El Grupo y Tienda") — antes 12px abajo AQUÍ, más los
       10px propios del último ítem de dentro (más abajo), más los 8px del
       <li> padre (".wp-block-navigation-item", más abajo): 30px
       apilados antes del siguiente grupo. Solo se queda el margen
       superior, para separar del botón que lo abre. */
    .menu-principal-nuevo .wp-block-navigation__responsive-container .wp-block-navigation__submenu-container {
        margin: 12px 0 0 !important;
        padding: 10px !important;
        background-color: #ffffff !important;
        border-radius: var(--radio-boton);
        box-shadow: none;
    }
    /* "width:100%" (23/08/2026, a petición expresa: "en los submenús...
       hay que pulsar en el mismo texto, el resto de la superficie del
       botón no hace nada") — mismo fallo y misma corrección que ya se
       aplicó a los ítems de nivel 1 más abajo (ver comentario en
       ".wp-block-navigation__container > .wp-block-navigation-item >
       .wp-block-navigation-item__content"): el enlace real
       (".wp-block-navigation-item__content") no ocupa por sí solo todo el
       ancho de su <li> — se queda ajustado a su propio texto — así que el
       marco/fondo del botón (pintado en el <li>) tenía zonas que
       visualmente parecían parte del botón pero no eran clicables. Solo
       faltaba aplicar aquí el mismo arreglo que en nivel 1. */
    .menu-principal-nuevo .wp-block-navigation__responsive-container .wp-block-navigation__submenu-container .wp-block-navigation-item__content {
        padding: 11px 10px !important;
        font-weight: 500;
        font-size: 0.95rem;
        width: 100%;
        box-sizing: border-box;
    }

    /* Nivel 1 — hijos directos del menú principal (tengan submenú o no,
       ej. "El Grupo" y "Tienda" miden y se ven igual de fuertes): fondo
       lavanda claro (--scout-global-fondo, el mismo tono que usa el resto
       del sitio) + borde fino + texto morado, en vez del morado sólido de
       antes. Ancho forzado al 100% porque los ítems SIN submenú (un
       simple enlace, sin la fila flex de los que sí tienen) se quedaban
       más estrechos, ajustados a su propio texto en vez de ocupar todo el
       ancho como sus hermanos (visto el 12/08/2026). */
    .menu-principal-nuevo .wp-block-navigation__responsive-container .wp-block-navigation__container > .wp-block-navigation-item {
        --item-color: var(--scout-global-base);
        background-color: var(--scout-global-fondo) !important;
        border: 1px solid var(--scout-global-borde);
        border-radius: var(--radio-boton);
        margin-bottom: 8px;
        width: 100%;
        box-sizing: border-box;
    }
    .menu-principal-nuevo .wp-block-navigation__responsive-container .wp-block-navigation__container > .wp-block-navigation-item > .wp-block-navigation-item__content {
        width: 100%;
        box-sizing: border-box;
    }
    /* Ítem activo (página actual): mismo lenguaje claro, pero con un tono
       de fondo más marcado y borde más grueso para que siga destacando
       sin volver al bloque sólido. Selector con la misma cadena completa
       que el de nivel 1 de arriba (en vez del ".current-menu-item" suelto
       de antes, con menos clases) para que gane la cascada de forma
       explícita — con la especificidad de antes, este ajuste nunca llegó
       a aplicarse en la práctica (el de nivel 1 ganaba siempre). */
    .menu-principal-nuevo .wp-block-navigation__responsive-container .wp-block-navigation__container > .wp-block-navigation-item.current-menu-item {
        background-color: var(--scout-global-borde) !important;
        border: 2px solid var(--scout-global-base);
    }

    /* Nivel 2 y siguientes — cualquier ítem dentro de un submenú, sea
       cual sea su profundidad (2, 3...): blanco con marco morado y
       texto morado, como el desplegable de escritorio. */
    .menu-principal-nuevo .wp-block-navigation__responsive-container .wp-block-navigation__submenu-container .wp-block-navigation-item {
        --item-color: var(--scout-global-base);
        background-color: #ffffff !important;
        border: 1px solid var(--scout-global-base);
        border-radius: var(--radio-boton);
        margin-bottom: 10px;
    }

    /* Botón "Acceder"/"Salir" al final del panel.
       "margin-bottom" (18/08/2026): sin él, este bloque (que no es un
       ".wp-block-navigation-item" como los demás, así que no hereda su
       "margin-bottom:8px" de la regla de nivel 1) quedaba pegado sin aire
       al siguiente ítem del panel (ej. "ADMIN"), dando la sensación visual
       de dos botones fundidos/apilados en vez de separados (visto el
       18/08/2026). */
    .menu-principal-nuevo .wp-block-navigation__responsive-container .wp-block-loginout {
        margin-top: 16px;
        margin-bottom: 8px;
    }
    .menu-principal-nuevo .wp-block-navigation__responsive-container .wp-block-loginout a {
        display: block;
        text-align: center;
        padding: 12px;
        border-radius: var(--radio-boton);
        background-color: var(--scout-global-fondo);
        border: 1px solid var(--scout-global-borde);
        box-sizing: border-box;
        color: var(--scout-global-base) !important;
        font-weight: 700;
        text-decoration: none;
    }
}
