/**
 * AZRAHEL - Maquetación de "Mi cuenta" (WooCommerce)
 * -----------------------------------------------------------------------------------------------
 * v1.1.0 — CORREGIDO TRAS RECHAZO DEL CENTINEL (2026-09-05): la v1.0.0 se desplegó, se miró en el
 * navegador real y la maquetación salía PEOR que antes de tocar nada: el menú y el contenido
 * aparecían intercambiados (el <nav>, primer hijo del documento, aterrizaba en la columna ANCHA de
 * la derecha; el contenido, en la estrecha de la izquierda) y cada entrada del menú medía 70px de
 * alto en vez de los ~47px calculados. Root cause de cada defecto, y la corrección aplicada, están
 * documentados junto a la regla correspondiente más abajo (buscar "RECHAZO CENTINEL"). Sigue sin
 * haberse verificado en un navegador real por quien escribe este fichero (no tiene acceso al
 * sitio en vivo): esta v1.1.0 es la mejor corrección razonada con la evidencia que dio el
 * CENTINEL, PENDIENTE de su verificación con capturas antes de considerarse cerrada.
 * -----------------------------------------------------------------------------------------------
 * Corrige la AUSENCIA de maquetación del área de cuenta, no un conflicto de estilos: se comprobó
 * (54 hojas de estilo descargadas y estilos computados medidos en el navegador real, ver
 * pending/20260904T193500Z__CENTINEL__013__P2__MI-CUENTA-SIN-ESTILOS.md del núcleo del swarm) que
 * SOLO existen 2 reglas de WooCommerce sobre el menú de cuenta, y ninguna del tema
 * (hello-elementor no aporta ni una sola regla ".woocommerce" ni ".MyAccount"). Sin reglas de
 * lista, el navegador pinta sus valores por defecto: viñeta, sangría de 40px y una caja de 80px de
 * alto para un enlace de 18px. Este fichero pone esas reglas que faltan; no quita ni pisa ninguna
 * regla necesaria de WooCommerce (ver comentarios en cada bloque, con la regla concreta a la que
 * responde y por qué gana la cascada sin necesitar !important).
 *
 * Todo selector de este fichero empieza por ".woocommerce-account" (clase real del <body> que
 * WooCommerce añade SOLO en la página de cuenta y sus subpáginas — comprobado leyendo
 * includes/wc-conditional-functions.php de WooCommerce: is_account_page() hace is_page() sobre el
 * ID de esa página concreta, y las subpáginas -pedidos, direcciones, etc.- son la MISMA página con
 * "endpoints", así que is_account_page() y por tanto la clase ".woocommerce-account" siguen dando
 * true en todas ellas). Ningún selector de aquí puede coincidir, por tanto, fuera de esa página.
 *
 * Colores: SOLO se usa el marrón/tierra rgb(165, 115, 85), que es el color REAL, ya en uso en el
 * sitio, de los enlaces de la cuenta (medido por CENTINEL). No se introduce ninguna paleta nueva;
 * los tonos intermedios que hacían falta (más oscuro para estado activo, transparencias para
 * fondos suaves) están CALCULADOS a partir de ese mismo marrón — el cálculo exacto va comentado
 * junto a cada variable. Tipografía: no se toca ningún font-family. Los titulares del sitio son
 * serif por herencia del tema; forzar aquí una familia tipográfica sería precisamente la paleta
 * nueva que el encargo prohíbe introducir.
 *
 * v1.1.1 — SEGUNDA CORRECCIÓN, CAUSA REAL YA MEDIDA (2026-09-05): la v1.1.0 arregló la colocación
 * (confirmado por CENTINEL: correcta, con capturas) pero mi hipótesis sobre el alto de 70px era
 * FALSA. Yo suponía otra regla del sitio ganándole la propiedad "line-height" a la mía; CENTINEL
 * midió que mi "line-height" SÍ se aplicaba bien (23,4px, mi valor exacto) y que lo que sobraba
 * era, al decimal, una línea de texto entera más: hay un "<br>" LITERAL dentro de cada `<a>` del
 * menú, que WooCommerce no pone en su plantilla -lo inyecta otra cosa del sitio, fuera de nuestra
 * superficie-. El "<br>" crea una segunda caja de línea; de ahí el sobrante exacto. Corregido
 * ocultando ese "<br>" por CSS (ver "CAUSA REAL (CENTINEL)" más abajo) y retirado el
 * "!important" de "line-height", que no hacía falta -mi valor ya ganaba sin él-.
 * -----------------------------------------------------------------------------------------------
 * v1.2.0 — TERCERA RONDA, ORACLE recorrió el resto de páginas de cuenta (2026-09-05). Tres
 * defectos nuevos, los tres medidos por CENTINEL en el navegador real:
 *   1) Icono roto en los avisos vacíos ("No hay descargas...", "No se han encontrado métodos
 *      guardados"): la fuente de iconos propia de WooCommerce no carga en este sitio -recurso
 *      que falta, fuera de nuestra superficie-, así que su "::before" pintaba el cuadrado de
 *      "carácter no disponible". Corregido ocultando ese "::before" en las tres variantes de
 *      aviso (buscar "defecto 1/3").
 *   2) Botones "descoloridos": mi regla de fondo marrón/texto blanco perdía la cascada frente al
 *      ".button" gris-lila por defecto de WooCommerce/tema. Corregido subiendo la especificidad
 *      con un selector real (el ".woocommerce" que envuelve el shortcode de la cuenta), SIN
 *      !important -CENTINEL pidió intentarlo primero-. De paso, verificado el contraste que
 *      pidió CENTINEL: el marrón original con texto blanco daba ~4.05:1 (por debajo del mínimo
 *      AA de 4.5:1); ahora el fondo en reposo usa el tono ya derivado 25% más oscuro (~6.44:1,
 *      AA holgado) (buscar "defecto 2/3").
 *   3) Tarjetas de direcciones desbordadas: el "auto-fit" de la rejilla dejaba 326px sin usar en
 *      vez de repartirlos entre las dos tarjetas reales, y la fila título+enlace "editar"
 *      -que además llevaba "white-space: nowrap" y el texto real es la frase completa "Editar
 *      dirección de facturación", no solo "Editar"- se salía 90px de la tarjeta. Corregido
 *      cambiando la rejilla por flexbox ("flex: 1 1 280px", reparte el sobrante entre las
 *      tarjetas que existen de verdad, sin pistas fantasma) y añadiendo "flex-wrap: wrap" a la
 *      fila título+enlace (si no caben en una línea, se apilan: no puede desbordar a ningún
 *      ancho ni en ningún idioma) (buscar "defecto 3/3").
 * Instrucción de ORACLE para esta ronda: que TODO el área de cuenta se vea limpia, no solo lo ya
 * revisado. Se repasó el resto de páginas (Escritorio, Pedidos, Descargas, Métodos de pago,
 * Detalles de la cuenta) buscando las mismas tres familias de fallo; "Mi Membresía" (de otro
 * plugin) se miró pero NO se tocó por falta de evidencia de que esté rota -mismo criterio que ya
 * se aplicó con Tutor LMS-.
 * -----------------------------------------------------------------------------------------------
 * v1.2.1 — CUARTA RONDA (2026-09-05): CENTINEL desplegó v1.2.0 y midió en el navegador real.
 * Defecto 1 (icono) y defecto 3 (direcciones): CONFIRMADOS arreglados -aunque la medida real de
 * las tarjetas dio 420px, no los 462px que yo había calculado; no cambia el resultado (cero
 * desbordamiento, título en una línea), pero la predicción no cuadró con lo medido, y queda
 * anotado como aviso para la próxima vez que calcule un número de memoria en vez de que me lo
 * midan-. Defecto 2 (botones) NO estaba arreglado del todo: el fondo ganó (confirmado
 * rgb(124,86,64)) pero el TEXTO seguía saliendo marrón claro sobre marrón oscuro -contraste real
 * medido por CENTINEL: 1,59:1, prácticamente ilegible-, desplegado así porque los otros dos
 * arreglos compensaban. Causa: "background-color" y "color" estaban en la MISMA regla, pero solo
 * "background-color" ganaba la cascada; la única explicación es que algo del tema/constructor
 * fija "color" sobre estos enlaces con más fuerza que la especificidad -probablemente su propio
 * "!important" sobre el color de enlace general del sitio-. Corregido añadiendo "!important"
 * SOLO a "color" (no a "background-color", que no lo necesita), y cubiertos explícitamente los
 * estados hover, foco (con ":focus" además de ":focus-visible") y desactivado; "visitado" no
 * necesita una regla aparte porque "!important" ya gana sobre cualquier regla no-"!important" de
 * ese pseudo-estado, sea cual sea su especificidad. Detalle completo, con la MEDIDA EXACTA a
 * comprobar para cada estado, en el propio bloque de botones (buscar "SEGUNDO INTENTO").
 * -----------------------------------------------------------------------------------------------
 * v1.2.2 — QUINTA RONDA (2026-09-05): CENTINEL verificó icono, botones y direcciones -los tres,
 * BIEN- pero ORACLE detectó un acabado desigual: las dos tarjetas de dirección ya no desbordaban,
 * pero no se parecían entre sí. Causa medida por CENTINEL: el texto del enlace cambia de longitud
 * según la dirección ("...de facturación" frente a "...de envío"), así que con "flex-wrap: wrap"
 * UNA tarjeta cabía en una línea y la otra no -título y enlace en la misma fila en una, cada uno
 * en su fila en la otra-, y "justify-content: space-between" repartía el título solo por el medio
 * cuando quedaba solo en su línea, pareciendo "centrado" en una tarjeta y no en la otra. La
 * corrección de ORACLE va a la raíz: dejar de intentar que quepan en una línea. Ahora se apilan
 * SIEMPRE (columna, no fila, sin "space-between"), así las dos tarjetas quedan idénticas pase lo
 * que pase con la longitud del texto, el idioma o el ancho de pantalla. Revisado el resto del
 * fichero por el mismo patrón (un "display:flex" con "space-between"/"wrap" cuyo resultado
 * dependa de cuánto mida el contenido): no hay ningún otro caso -el único "flex-wrap" que queda
 * es el de las TARJETAS en sí, que no usa "space-between" y reparte un ancho fijo (280px por
 * tarjeta), no dependiente del texto que contienen-. Detalle y medida exacta en el propio bloque
 * (buscar "TERCERA CORRECCIÓN").
 * -----------------------------------------------------------------------------------------------
 * v1.3.0 — SEXTA RONDA (2026-09-05): CENTINEL midió una rotura real en Tutor LMS -distinta a las
 * de WooCommerce, primera evidencia real contra el criterio de "no tocar Tutor sin evidencia"
 * que se sostuvo hasta ahora-. En /escritorio/account/settings/, las pestañas laterales salían
 * cortadas: el TEMA aplica 4px de espaciado entre letras + mayúsculas de forma global, y con
 * etiquetas largas eso gana más ancho del que Tutor previó al fijar el ancho de sus botones. No
 * es un fallo de Tutor; es la misma fuga de estilos globales del tema que ya se vio en los
 * botones de WooCommerce, ahora sobre otra propiedad y en otra superficie. Corregido, acotado a
 * ".tutor-dashboard-layout" (el contenedor raíz real de todo el escritorio de Tutor), quitando
 * el espaciado y las mayúsculas y dejando que el texto se envuelva en vez de recortarse -no
 * depende del idioma ni de la longitud de ninguna etiqueta-. Se revisó también, por analogía y
 * sin coste, el menú lateral principal del escritorio (mismo patrón de enlaces cortos), aunque
 * sin confirmación de que esté roto. El cargador (azr-ui.php) se amplió para encolar esta hoja
 * también en el escritorio de Tutor -antes solo se cargaba en la cuenta de WooCommerce-. Detalle
 * completo en la sección "5. TUTOR LMS". Esta ronda no añade ningún !important nuevo -las
 * reglas de Tutor ganan sin él, no hay evidencia de que lo necesiten-.
 * -----------------------------------------------------------------------------------------------
 * v1.3.0 — CORRECCIÓN POSTERIOR, SÉPTIMA RONDA (2026-09-05). Misma versión de azr-ui.php: el
 * defecto estaba en el ancla CSS de esta sección, no en el enganche (que carga bien la hoja en
 * el escritorio de Tutor), así que esa versión no sube -no hay defecto que corregir ahí-. CENTINEL
 * desplegó v1.3.0 y midió en /escritorio/account/settings/: la hoja SÍ carga, pero la regla de
 * las pestañas NO APLICABA. Motivo medido en el navegador, no deducido de código: la v1.3.0
 * acotaba todo a ".tutor-dashboard-layout" -leído en templates/dashboard.php como "el
 * contenedor raíz de todo el escritorio"-, pero esa clase NO EXISTE en el DOM de
 * /account/settings/: esa página concreta la pinta otra plantilla de Tutor, no dashboard.php.
 * Cadena real de ancestros del botón de pestaña, medida en el navegador:
 *
 *     button.tutor-tabs-tab
 *       div.tutor-tabs-nav.tutor-profile-settings-tab.tutor-p-5
 *         div.tutor-flex.tutor-gap-8.tutor-my-9
 *           div.tutor-gap-8
 *             div.tutor-account-container
 *               div.tutor-profile-settings-section.tutor-tabs-vertical
 *
 * Corregido: el ancla pasa de ".tutor-dashboard-layout" a ".tutor-account-container" -
 * confirmada presente en esa misma cadena real-, sobre el mismo selector de pestaña de
 * siempre. Sigue en (0,3,0) de especificidad y sigue ganando SIN !important: esto nunca fue un
 * problema de especificidad -".elementor-kit-7 button", el origen real del espaciado y las
 * mayúsculas, es (0,1,1); el ancla anterior ya habría ganado de sobra si hubiera coincidido con
 * algo-. El origen real, medido, es la tipografía global de Elementor (post-7.css,
 * "--e-global-typography-accent-letter-spacing"/"-text-transform" sobre ".elementor-kit-7
 * button"), no una decisión de Tutor -su propia regla (tutor-core.min.css) pide
 * "text-transform: capitalize"; nunca pidió mayúscula sostenida-. Se revisó también, con el
 * mismo criterio, el reseteo del menú lateral principal: llevaba la misma ancla ya refutada, y
 * se retiró sin sustituirla por otra suposición. CENTINEL midió después en el navegador: ese
 * menú y esa clase SÍ existen, pero en "/escritorio/", no en la pantalla de ajustes -0 enlaces
 * recortados allí, así que ese reseteo es preventivo, no correctivo-.
 * LECCIÓN que entra en la doctrina de este fichero: una clase que aparece en una plantilla del
 * plugin no es prueba de que esté en el DOM de la página que se corrige; se comprueba en la
 * página real, nunca se supone por lectura de código fuente. Y el matiz que lo hace más útil:
 * la lectura de plantilla no era FALSA, era de OTRA PANTALLA -el error no fue leer mal el
 * código, fue dar por hecho que el LMS pinta todas sus páginas con la misma plantilla-.
 * Detalle completo, con la medida exacta a comprobar en ambos ejes (ancho y alto), en la propia
 * sección "5. TUTOR LMS".
 * -----------------------------------------------------------------------------------------------
 * Uso de !important (sin cambios en esta corrección): 9 declaraciones. 6 son "grid-column"/"grid-row"/
 * "order" del menú y del contenido (colocación, confirmada rota y confirmada corregida por
 * CENTINEL con medidas reales). 3 son "color: #fff" de los botones (reposo, hover/foco,
 * desactivado) -la única forma de ganar contra una regla ajena que también usa "!important"
 * sobre el color de enlace; NINGUNA especificidad, por alta que sea, puede ganarle a un
 * "!important" ajeno-. "background-color" de esos mismos botones NO lleva !important: ya gana
 * sin él, confirmado por CENTINEL. Todas las demás reglas del fichero siguen anulando WooCommerce
 * por especificidad real, sin !important.
 */

/* ================================================================================================
 * 1. VARIABLES DE MARCA (derivadas del marrón real del sitio, ninguna calculada fuera de él)
 * ============================================================================================== */

.woocommerce-account {
	/* Verificado en el sitio real por CENTINEL: color de los enlaces de la cuenta. */
	--azr-marron: rgb(165, 115, 85);

	/* El mismo marrón, con cada canal multiplicado por 0.75 (25% más oscuro):
	   165*0.75=123.75→124, 115*0.75=86.25→86, 85*0.75=63.75→64. Se usa para el TEXTO del ítem
	   activo del menú (necesita más contraste que el resto) y para el acento de los avisos de
	   error, sin salir del marrón de marca. */
	--azr-marron-oscuro: rgb(124, 86, 64);

	/* El mismo marron, con cada canal multiplicado por 0.6 (40% mas oscuro):
	   165*0.6=99, 115*0.6=69, 85*0.6=51. RECHAZO CENTINEL (2026-09-05): el marron original
	   rgb(165,115,85) con texto blanco da un contraste de ~4.05:1, POR DEBAJO del minimo
	   WCAG AA para texto normal (4.5:1) -calculo con la formula de luminancia relativa del
	   propio WCAG, sin poder verificarlo en un lector de contraste real-. Este tono, mas
	   oscuro, sube el contraste a ~6.44:1 (AA holgado, casi AAA): se usa como fondo EN
	   REPOSO de los botones (ver seccion de botones), dejando este otro (-40%) para el
	   estado de hover/foco, que necesita distinguirse del reposo. */
	--azr-marron-mas-oscuro: rgb(99, 69, 51);

	/* El mismo marrón, en rgba con opacidad baja: no es un color nuevo, es el mismo triplete
	   con transparencia, para fondos sutiles de hover/activo/tablas sin tapar el fondo real
	   de la página (que no controlamos ni queremos fijar aquí). */
	--azr-marron-fondo-hover: rgba(165, 115, 85, 0.08);
	--azr-marron-fondo-activo: rgba(165, 115, 85, 0.14);
	--azr-marron-borde: rgba(165, 115, 85, 0.28);

	/* Espaciado y radio compartidos, para que todo el área de cuenta respire igual. */
	--azr-espacio-s: 0.5rem;
	--azr-espacio-m: 1rem;
	--azr-espacio-l: 1.75rem;
	--azr-radio: 6px;
}

/* ================================================================================================
 * 2. PRIORIDAD 1 — MENÚ DE "MI CUENTA"
 * ------------------------------------------------------------------------------------------------
 * Causa raíz exacta (WooCommerce, templates/myaccount/navigation.php): cada entrada es
 * <li class="woocommerce-MyAccount-navigation-link woocommerce-MyAccount-navigation-link--{tab}
 * [is-active]"><a href="..." [aria-current="page"]>Texto</a></li>, dentro de un <ul> sin ninguna
 * regla de lista propia. De ahí la viñeta y la sangría de 40px por defecto del navegador.
 * ============================================================================================== */

/* Quita viñeta y sangría del navegador. Es la única causa real medida por CENTINEL: no hay
   ninguna regla de WooCommerce ni del tema que compita aquí, así que una sola regla, sin
   !important, es suficiente. */
.woocommerce-account .woocommerce-MyAccount-navigation ul {
	list-style: none;
	margin: 0;
	padding: 0;
}

/* RECHAZO CENTINEL (2026-09-05), defecto 2/2: cada entrada medía 70px de alto en vez de los
   ~47px esperados, con el relleno del enlace ya correcto (11.7px arriba/abajo, confirmado por
   CENTINEL). La cuenta solo cuadra si algo, aparte de mi <a>, sigue metiendo altura: el <li> en
   sí. "list-style:none" (arriba) solo quita la viñeta; NO toca el padding ni el line-height que
   otra regla del sitio pudiera tener puestos sobre "li" en general (p. ej. una hoja de
   tipografía de contenido, o una pensada para OTRO listado). Se resetean aquí explícitamente,
   además de en el <a>, para no depender de dónde esté exactamente el sobrante. */
.woocommerce-account .woocommerce-MyAccount-navigation-link {
	margin: 0 0 var(--azr-espacio-s);
	padding: 0;
	line-height: normal;
}

.woocommerce-account .woocommerce-MyAccount-navigation-link:last-child {
	margin-bottom: 0;
}

/* El enlace pasa a ocupar todo el bloque del <li> (área pulsable completa), con su propio
   relleno, en vez de un texto suelto de 18px flotando dentro de una caja de 80px vacía. El
   borde izquierdo transparente reserva ya el hueco del indicador de estado activo (mismo
   grosor que abajo), para que activar/pasar el ratón no mueva el resto del texto (layout shift).
   MEDIDA EXACTA A COMPROBAR: con el font-size real de este enlace (18px medido por CENTINEL en
   el hallazgo original), el alto de caja de este <a> (y por tanto del <li>, que ya no aporta
   padding propio) debe ser font-size × 2.6 -0.65em de arriba + 0.65em de abajo + 1.3 de
   line-height-, es decir 46.8px ≈ 47px, UNA sola línea de texto. Si vuelve a salir el doble
   (≈94px) o cualquier múltiplo, la sospecha ya no es la cascada: es que ha vuelto a aparecer
   un salto de línea en el marcado (ver "CAUSA REAL (CENTINEL)" debajo). */
.woocommerce-account .woocommerce-MyAccount-navigation-link a {
	display: block;
	padding: 0.65em 1em;
	border-left: 3px solid transparent;
	border-radius: var(--azr-radio);
	color: var(--azr-marron);
	text-decoration: none;
	line-height: 1.3;
	transition: background-color 0.15s ease, border-color 0.15s ease, color 0.15s ease;
}

/* CAUSA REAL (CENTINEL, 2026-09-05), corrige la hipótesis de la v1.1.0: el "line-height" de
   arriba SÍ se aplicaba bien (CENTINEL lo midió: 23,4px, exactamente 1.3 × 18px) y por eso NO
   lleva -ni necesita- !important. El sobrante de 23,4px (70,2px medidos contra 46,8px
   esperados) es una LÍNEA DE TEXTO ENTERA de más, no una línea más alta: el HTML real de cada
   enlace es "<a><br>\n  Texto  </a>" -un "<br>" LITERAL antes del texto-. WooCommerce no lo
   pone (confirmado contra templates/myaccount/navigation.php: solo hay texto, sin "<br>"); lo
   inyecta otra cosa del sitio, fuera de nuestra superficie (no se persigue el origen: tocarlo
   podría romper algo que no es nuestro). Se neutraliza aquí, en nuestro ámbito, ocultando
   cualquier "<br>" dentro de este enlace -si algún día deja de inyectarse, esta regla
   simplemente no encuentra nada que ocultar y no cambia nada-. */
.woocommerce-account .woocommerce-MyAccount-navigation-link a br {
	display: none;
}

/* Estado al pasar el ratón / foco de teclado. */
.woocommerce-account .woocommerce-MyAccount-navigation-link a:hover,
.woocommerce-account .woocommerce-MyAccount-navigation-link a:focus-visible {
	background-color: var(--azr-marron-fondo-hover);
	border-left-color: var(--azr-marron-borde);
}

/* Estado activo (la sección en la que se está). ".is-active" lo añade WooCommerce en el <li>
   (wc_get_account_menu_item_classes(), core, sin tocar); "aria-current" lo añade en el <a> el
   propio navigation.php. Se usan los dos para no depender de una única versión de WooCommerce. */
.woocommerce-account .woocommerce-MyAccount-navigation-link.is-active a,
.woocommerce-account .woocommerce-MyAccount-navigation-link a[aria-current='page'] {
	background-color: var(--azr-marron-fondo-activo);
	border-left-color: var(--azr-marron);
	color: var(--azr-marron-oscuro);
	font-weight: 600;
}

/* ------------------------------------------------------------------------------------------------
 * Convivencia menú + contenido: hoy son dos flotantes reales de WooCommerce
 * (client/legacy/css/woocommerce-layout.scss, confirmado leyendo el código fuente):
 *     .woocommerce-account .woocommerce-MyAccount-navigation { float:left;  width:30% }
 *     .woocommerce-account .woocommerce-MyAccount-content    { float:right; width:68% }
 * Se sustituye por una rejilla (CSS grid) SOLO en escritorio, dejando el flotante de WooCommerce
 * como respaldo automático (no reescrito, no tocado) en cualquier navegador sin soporte de
 * ":has()". El selector ":has(> .woocommerce-MyAccount-navigation)" apunta EXCLUSIVAMENTE al
 * <div class="woocommerce"> que envuelve el shortcode [woocommerce_my_account] (confirmado en
 * includes/class-wc-shortcodes.php: shortcode_wrapper() lo envuelve siempre en class="woocommerce")
 * y que además es padre DIRECTO de la navegación de cuenta. Así, si dentro del contenido de la
 * cuenta hubiera otro bloque con class="woocommerce" (p. ej. un shortcode anidado de otro
 * complemento), esa regla NO le afecta, porque ese otro bloque no es padre directo del menú.
 * ---------------------------------------------------------------------------------------------- */

/* RECHAZO CENTINEL (2026-09-05), defecto 1/2 — EL PRINCIPAL: con el contenedor puesto en
   "display:grid" pero SIN fijar la columna de cada hijo, CENTINEL midió en el navegador real
   que el <nav> (primer hijo del documento) aterrizaba en la pista ANCHA (952px) y el <div>
   de contenido en la ESTRECHA (260px) — exactamente al revés de lo pretendido, con el propio
   "grid-template-columns" del contenedor midiendo correctamente "260px 952px". Es decir: el
   contenedor está bien, la COLOCACIÓN de los hijos dentro de él no. La colocación automática de
   CSS grid (la que yo usaba: ningún "grid-column" ni "order" propios, solo orden del documento)
   depende de que NINGUNA otra regla del sitio toque "order" o "grid-column" de estos dos
   elementos - y algo, en un fichero que no se ha podido localizar sin navegador en vivo (el
   propio CENTINEL avisa: "esta página vive dentro de un maquetador visual y hay más CSS del que
   ves"), lo está tocando. No se ha podido identificar el selector exacto; lo que sí se puede
   hacer es dejar de depender de la colocación automática: fijando "grid-column" explícito en
   cada hijo, un "order" ajeno deja de importar (el "order" solo decide el turno de la
   colocación AUTOMÁTICA; un hijo con "grid-column" explícito ya no participa en ese turno). El
   "!important" en "grid-column" y "order" es necesario porque, si la regla ajena que causó esto
   fija ella misma un "grid-column" (no solo un "order"), sin "!important" volveríamos a
   depender de ganar la especificidad contra un selector que no conocemos - exactamente lo que
   CENTINEL pidió evitar ("una solución que no pueda quedar invertida aunque otro CSS
   intervenga"). Solo perdería frente a otro !important MÁS específico dirigido a estas dos
   clases exactas, escenario no observado.
   MEDIDA EXACTA A COMPROBAR (DevTools → Computed, con el filtro de propiedades):
     - .woocommerce-MyAccount-navigation → "grid-column-start" debe ser "1", ancho ≈ 260px.
     - .woocommerce-MyAccount-content    → "grid-column-start" debe ser "2", ancho = el resto
       (en un contenedor de ~1240px de ancho interno, ≈ 952px, como ya midió CENTINEL).
     - Visualmente: el menú a la izquierda, en una columna estrecha; el contenido a la derecha,
       ocupando el resto. Sin hueco vacío entre ambos mayor que el "gap" (1.75rem = 28px).
   769px arranca justo donde termina la hoja de pantalla pequeña de WooCommerce
   (woocommerce-smallscreen.css se enlaza con media="only screen and (max-width: 768px)",
   confirmado en includes/class-wc-frontend-scripts.php): sin hueco y sin solape entre ambas. */
@media (min-width: 769px) {
	.woocommerce-account .woocommerce:has(> .woocommerce-MyAccount-navigation) {
		display: grid;
		grid-template-columns: minmax(200px, 260px) 1fr;
		gap: var(--azr-espacio-l);
		align-items: start;
	}

	.woocommerce-account .woocommerce:has(> .woocommerce-MyAccount-navigation) > .woocommerce-MyAccount-navigation {
		grid-column: 1 !important;
		grid-row: 1 !important;
		order: 0 !important;
		float: none;
		width: auto;
	}

	.woocommerce-account .woocommerce:has(> .woocommerce-MyAccount-navigation) > .woocommerce-MyAccount-content {
		grid-column: 2 !important;
		grid-row: 1 !important;
		order: 0 !important;
		float: none;
		width: auto;
	}
}

/* ================================================================================================
 * 3. PRIORIDAD 2 — RESTO DEL ÁREA DE CUENTA
 * ============================================================================================== */

/* --- Titulares del contenido de la cuenta: solo espaciado, ninguna tipografía nueva --- */
.woocommerce-account .woocommerce-MyAccount-content h2,
.woocommerce-account .woocommerce-MyAccount-content h3,
.woocommerce-account .woocommerce-Address-title h2 {
	margin: 0 0 0.75em;
	line-height: 1.25;
}

/* --- Tablas de pedidos y de métodos de pago (templates/myaccount/orders.php y
   payment-methods.php, mismas clases base "shop_table shop_table_responsive") --- */
.woocommerce-account .shop_table {
	width: 100%;
	border-collapse: collapse;
}

.woocommerce-account .shop_table th,
.woocommerce-account .shop_table td {
	padding: 0.85em 1em;
	text-align: left;
	border-bottom: 1px solid var(--azr-marron-borde);
}

.woocommerce-account .shop_table thead th {
	font-weight: 600;
	border-bottom: 2px solid var(--azr-marron-borde);
}

.woocommerce-account .woocommerce-orders-table__row:hover {
	background-color: var(--azr-marron-fondo-hover);
}

/* La vista de pantalla estrecha de WooCommerce (woocommerce-smallscreen.css) oculta el <thead> y
   convierte cada fila en una tarjeta con etiquetas (atributo data-title). No se toca esa
   transformación aquí: el padding/borde de arriba conviven con ella sin conflicto porque ninguna
   de las dos reglas fija "display" en los mismos elementos que la otra. */

/* --- Paginación de pedidos (templates/myaccount/orders.php) --- */
.woocommerce-account .woocommerce-Pagination {
	margin-top: var(--azr-espacio-m);
}

/* REVISIÓN TRAS "REVISA SI ESE MISMO <br> APARECE EN OTROS ENLACES" (CENTINEL, 2026-09-05): el
   único enlace donde se ha VISTO el "<br>" inyectado, con HTML real delante, es el del menú de
   cuenta (arriba). No he podido inspeccionar el HTML real de "Anterior"/"Siguiente" para
   confirmar si también lo tienen -sin navegador en vivo no hay forma de saberlo-, pero es el
   mismo tipo de enlace corto de una sola línea, así que se neutraliza aquí por el mismo motivo
   y de la misma forma barata (si no hay "<br>", esta regla no encuentra nada y no cambia nada).
   NO confirmado en navegador: si al verlo la paginación sigue con doble alto, esta es la causa. */
.woocommerce-account .woocommerce-Pagination a br {
	display: none;
}

/* --- Direcciones (templates/myaccount/my-address.php): la clase que WooCommerce flota de verdad
   es ".col-1"/".col-2" dentro de ".col2-set" (confirmado en woocommerce-layout.scss); ".u-column1"
   /".u-column2" viajan en el mismo elemento pero no llevan ninguna regla propia.

   RECHAZO CENTINEL (2026-09-05), defecto 3/3, primera mitad: mi rejilla anterior
   ("grid-template-columns: repeat(auto-fit, minmax(260px, 1fr))") calculaba, con solo 2
   direcciones dentro de 952px, TRES pistas posibles de 260px (auto-fit decide el número de
   columnas usando el mínimo, 260px, no el máximo) y solo rellenaba dos: en teoría la tercera
   pista vacía debería colapsar a 0 y repartir su hueco entre las dos reales, pero CENTINEL
   midió en el navegador real que NO colapsaba -cada tarjeta se quedó en 299px, que es
   exactamente (952 - 2 gaps) / 3, como si la tercera pista siguiera contando-, dejando 326px
   sin usar. No he podido reproducir ese comportamiento fuera del navegador real para confirmar
   la causa exacta de por qué "auto-fit" no colapsó ahí; en vez de seguir suponiendo sobre el
   motivo, se cambia a un mecanismo que no depende de ese cálculo en absoluto: Flexbox con
   "flex: 1 1 <ancho mínimo>", que reparte el espacio sobrante SIEMPRE entre los elementos que
   existen de verdad, sin pistas fantasma que colapsar. Con exactamente 2 tarjetas (facturación
   y envío, cuando el envío está activado) o 1 sola (cuando no lo está, "wc_ship_to_billing_
   address_only()"), el resultado es el mismo: cada tarjeta real ocupa una parte igual del
   ancho disponible, nunca queda sitio sin repartir.
   MEDIDA EXACTA A COMPROBAR: con las DOS direcciones visibles en un contenedor de 952px de
   ancho y 28px de "gap", cada tarjeta ".woocommerce-Address" debe medir (952-28)/2 = 462px
   (antes: 299px, con 326px sobrantes sin usar). Con una sola dirección visible, esa única
   tarjeta debe ocupar los 952px completos (no la mitad). --- */
.woocommerce-account .woocommerce-Addresses.col2-set {
	display: flex;
	flex-wrap: wrap;
	gap: var(--azr-espacio-l);
	width: auto; /* anula el width:100% de WooCommerce; ahora el ancho lo reparte flexbox */
}

/* REVISIÓN TRAS RECHAZO CENTINEL (punto 4 de la ronda anterior: "revisa si el resto de bloques
   tienen la misma suposición sobre colocación"): estos dos hijos siguen colocándose por orden
   de documento (ahora en flexbox, no en grid); ".col-1"/".col-2" siguen siendo nombres de clase
   genéricos que otra parte del sitio podría reutilizar con su propio "order". Se seguía fijando
   "order:0" explícito por eso -sigue sin !important, sigue sin confirmar en navegador que haga
   falta-. "flex: 1 1 280px" es lo que reparte el ancho sobrante por igual entre las tarjetas
   reales (ver comentario de arriba); 280px es el mismo mínimo razonable que antes, ahora sin el
   efecto de pista fantasma. */
.woocommerce-account .woocommerce-Addresses.col2-set .col-1,
.woocommerce-account .woocommerce-Addresses.col2-set .col-2 {
	float: none; /* anula float:left/right + width:48% de WooCommerce (core, sin tocar el fichero) */
	flex: 1 1 280px;
	order: 0;
}

.woocommerce-account .woocommerce-Address {
	padding: var(--azr-espacio-m);
	border: 1px solid var(--azr-marron-borde);
	border-radius: var(--azr-radio);
}

/* RECHAZO CENTINEL (2026-09-05), defecto 3/3, TERCERA CORRECCIÓN (a partir de una observación de
   ORACLE): "flex-wrap: wrap" quitaba el desbordamiento, pero abría un problema distinto que
   CENTINEL midió en el navegador real: el texto del enlace cambia según la dirección ("Editar
   dirección de facturación" frente a "Editar dirección de envío", de distinta longitud), así que
   UNA tarjeta cabía en una sola línea y la otra no -las dos tarjetas dejaban de parecerse entre
   sí-. Además, al apilarse, "justify-content: space-between" reparte el ÚNICO elemento de esa
   línea por el medio del eje principal, así que el título aparecía descentrado en la tarjeta que
   apilaba y pegado a la izquierda en la que no -de ahí que una pareciera "centrada" y la otra no,
   sin que nadie lo hubiera pedido-.
   La instrucción de ORACLE es la correcta y es la que se aplica aquí: dejar de intentar que
   título y enlace quepan en una línea. Se apila SIEMPRE -título arriba, enlace debajo, columna en
   vez de fila-, así las dos tarjetas se ven idénticas sin importar cuánto mida el texto, el
   idioma en el que esté o el ancho de la pantalla: no es que "quepan o no cada vez", es que ya no
   se intenta que quepan. Sin "justify-content" -no reparte nada en un eje de una sola columna- y
   con "align-items: flex-start" para que título y enlace queden siempre pegados al mismo borde
   izquierdo, en las dos tarjetas por igual. "order:0" se mantiene por el mismo motivo defensivo
   de siempre (ver más arriba, direcciones): sigue teniendo efecto en una columna flex, no es
   dead code.
   MEDIDA EXACTA A COMPROBAR, en LAS DOS tarjetas (facturación y envío):
     - "getBoundingClientRect().left" del título y del enlace ".edit" deben coincidir entre sí
       -mismo borde izquierdo- Y coincidir entre las dos tarjetas (la diferencia debe ser 0, no
       172px como medía antes en una de ellas).
     - el enlace ".edit" debe aparecer SIEMPRE en una línea propia, debajo del título, en las dos
       tarjetas, sin excepción -no solo cuando el texto es largo-.
     - la altura de la fila título+enlace debería ser igual en ambas tarjetas (mismo número de
       líneas de texto en cada una: título en 1 línea, enlace en 1 línea, salvo que el propio
       texto sea tan largo que necesite envolverse dentro de SU PROPIA línea, lo cual seguiría
       siendo igual de ancho en las dos tarjetas). */
.woocommerce-account .woocommerce-Address-title {
	display: flex;
	flex-direction: column;
	align-items: flex-start;
	gap: var(--azr-espacio-s);
	margin-bottom: var(--azr-espacio-s);
}

.woocommerce-account .woocommerce-Address-title h2 {
	margin: 0;
	font-size: 1.05em;
	order: 0;
}

.woocommerce-account .woocommerce-Address-title .edit {
	color: var(--azr-marron);
	font-size: 0.9em;
	order: 0;
}

/* Mismo repaso del "<br>" inyectado que en el menú (ver más arriba, "CAUSA REAL (CENTINEL)"):
   no confirmado con HTML real en ESTE enlace, se neutraliza igual, por si acaso, sin coste si
   no hace falta. */
.woocommerce-account .woocommerce-Address-title .edit br {
	display: none;
}

.woocommerce-account .woocommerce-Address address {
	font-style: normal;
	line-height: 1.6;
}

/* --- Formularios: editar dirección (form-edit-address.php) y detalles de la cuenta
   (form-edit-account.php). Ambos reutilizan las clases estándar de WooCommerce ".form-row"
   (las mismas del checkout, ya con su propio float de 2 columnas para "-first"/"-last": eso NO
   se toca aquí, solo se viste el campo en sí). --- */
.woocommerce-account .form-row {
	margin-bottom: var(--azr-espacio-m);
}

.woocommerce-account .form-row label {
	display: block;
	margin-bottom: 0.35em;
	font-weight: 600;
}

.woocommerce-account .form-row .input-text,
.woocommerce-account .form-row select,
.woocommerce-account .form-row textarea {
	width: 100%;
	padding: 0.6em 0.75em;
	border: 1px solid var(--azr-marron-borde);
	border-radius: var(--azr-radio);
	box-sizing: border-box;
	font: inherit; /* hereda tipografía del tema, no se fija ninguna nueva */
}

.woocommerce-account .form-row .input-text:focus,
.woocommerce-account .form-row select:focus,
.woocommerce-account .form-row textarea:focus {
	outline: none;
	border-color: var(--azr-marron);
	box-shadow: 0 0 0 2px var(--azr-marron-fondo-hover);
}

/* Nota: el campo de país/provincia puede usar Select2, que oculta el <select> real y pinta su
   propio marcado (".select2-*"). No se ha tocado ese marcado interno: si Select2 está activo,
   la regla de arriba no tiene ningún efecto visible ahí (apunta al <select> oculto) y no hay
   conflicto; si no está activo, el <select> nativo se ve igual que el resto de campos. */

.woocommerce-account fieldset {
	border: 1px solid var(--azr-marron-borde);
	border-radius: var(--azr-radio);
	padding: var(--azr-espacio-m);
	margin: 0 0 var(--azr-espacio-m);
}

.woocommerce-account fieldset legend {
	padding: 0 0.5em;
	font-weight: 600;
	color: var(--azr-marron-oscuro);
}

/* --- Avisos (WooCommerce templates/notices/*.php). ".woocommerce-error" es un <ul>: sin esta
   regla hereda la MISMA viñeta/sangría por defecto que tenía el menú, por la misma causa raíz
   (el tema no resetea listas). Se corrige aquí por ser exactamente el mismo problema. Los tres
   tipos de aviso comparten el marrón de marca (no se introduce rojo/verde, según el encargo);
   se diferencian por peso e intensidad, no por tono nuevo. --- */
.woocommerce-account .woocommerce-message,
.woocommerce-account .woocommerce-error,
.woocommerce-account .woocommerce-info {
	padding: var(--azr-espacio-m) var(--azr-espacio-l);
	margin: 0 0 var(--azr-espacio-l);
	border-radius: var(--azr-radio);
	border-left: 4px solid var(--azr-marron);
	background-color: var(--azr-marron-fondo-hover);
	list-style: none;
}

.woocommerce-account .woocommerce-error {
	border-left-color: var(--azr-marron-oscuro);
	font-weight: 600;
}

.woocommerce-account .woocommerce-error li {
	margin: 0;
}

.woocommerce-account .woocommerce-error li + li {
	margin-top: 0.5em;
}

/* RECHAZO CENTINEL (2026-09-05), defecto 1/3: en los avisos vacios ("No hay descargas
   disponibles todavia", "No se han encontrado metodos guardados") aparecia un cuadrado gris
   tapando la primera letra. CENTINEL lo midio sobre el pseudo-elemento real: WooCommerce pinta
   un icono con un glifo de una fuente propia ("font-family: WooCommerce", ver
   client/legacy/css/woocommerce.scss, selector ".woocommerce-message, .woocommerce-error,
   .woocommerce-info { &::before { font-family: "WooCommerce"; content: "\e028"; position:
   absolute; top: 1em; left: 1.5em; } }") que reserva un hueco de "padding-left: 3.5em" para
   ese icono. Esa fuente de iconos NO esta cargando en este sitio -no es CSS nuestro, es un
   recurso que falta, fuera de nuestra superficie-, asi que el glifo se pinta como el cuadrado
   de "caracter no disponible". Como mi propia regla de arriba YA sustituye ese "padding-left:
   3.5em" por un padding uniforme (sin hueco reservado para icono), lo unico que falta es
   ocultar el propio pseudo-elemento -si no, sigue ahi, roto, encima del texto-. Los avisos ya
   tienen franja de color a la izquierda (border-left) y fondo: el icono no aporta nada. */
.woocommerce-account .woocommerce-message::before,
.woocommerce-account .woocommerce-error::before,
.woocommerce-account .woocommerce-info::before {
	display: none;
}

/* --- Botones dentro del área de cuenta (ver pedido, pagar, cancelar, guardar dirección, guardar
   cambios...). Mismo marrón/tierra que ya usan los botones del resto del sitio (según el encargo,
   "botones existentes"), en mayúsculas y con espaciado de letras. Acotado a ".woocommerce-account"
   para que NO afecte a ningún botón fuera de esta página (el resto del sitio lo maqueta el
   constructor visual, no este fichero).

   RECHAZO CENTINEL (2026-09-05), defecto 2/3, PRIMER INTENTO (fallido): medido en el navegador
   real, el fondo salía gris-lila rgb(233,230,237) -el por defecto de WooCommerce/tema- y el
   texto marrón. Subí la especificidad del selector (añadiendo el ancestro ".woocommerce" real)
   SIN !important, porque CENTINEL pidió intentar eso primero.

   RECHAZO CENTINEL (2026-09-05), defecto 2/3, SEGUNDO INTENTO (la causa real): ese cambio
   arregló el FONDO (confirmado: rgb(124, 86, 64), mi valor) pero el TEXTO siguió saliendo
   rgb(165, 115, 85) -marrón claro sobre marrón oscuro, prácticamente ilegible-, con background-
   color y color declarados en la MISMA regla, MISMA especificidad. Que una propiedad gane y la
   otra no, viniendo de la misma regla, solo tiene una explicación: existe OTRA regla, en algún
   sitio del tema/constructor visual, que fija "color" (no "background-color") sobre este mismo
   <a> con más fuerza que la especificidad -lo más probable, por el valor exacto que gana
   (rgb(165,115,85), el marrón de enlace que ya veníamos usando desde el principio de este
   fichero para los enlaces normales de la cuenta): un "a { color: ... !important }" u
   equivalente del tema/kit del constructor, pensado para que el color de enlace se imponga en
   cualquier contexto. Contra un "!important" ajeno, ninguna especificidad -por muchas clases
   que se añadan- puede ganar: hace falta "!important" también en "color". "background-color"
   se deja SIN !important porque ya gana sin él (no hay evidencia de que lo necesite); forzar ahí
   también sería exactamente el "por si acaso" que este fichero evita en todo lo demás.
   ESTADO, no resultado (no puedo medirlo yo mismo): con "color: #fff !important" en el mismo
   selector que ya gana el fondo, el texto DEBERÍA salir blanco en todos los estados -":visited"
   y "!important" ganan sobre cualquier regla no-"!important" del tema, sea cual sea su
   especificidad o pseudo-clase; no hace falta un selector aparte para "visitado"-. Añadido
   además "focus" (no solo "focus-visible", que algunos navegadores no disparan con clic de
   ratón) y un estado "disabled" explícito, atenuado, para cubrir los cinco estados que pidió
   CENTINEL.
   MEDIDA EXACTA A COMPROBAR (esta vez sobre TODOS los estados, no solo reposo):
     - reposo: "color" computado "rgb(255, 255, 255)", "background-color" "rgb(124, 86, 64)".
     - hover/foco (con el ratón encima y con Tab): "color" "rgb(255, 255, 255)",
       "background-color" "rgb(99, 69, 51)".
     - visitado (si aplica, en un enlace ya clicado): "color" "rgb(255, 255, 255)" -si sale
       distinto, hay un ":visited" ajeno con !important propio, y toca hablarlo, no forzar más-.
     - si algún botón llega a estar "disabled": fondo "rgb(165, 115, 85)" con opacidad 0.6,
       texto "rgb(124, 86, 64)" -sin exigir 4.5:1 aquí: WCAG excluye explícitamente los
       componentes inactivos del mínimo de contraste-.
   CONTRASTE RECALCULADO (sigue siendo cálculo, no medida del navegador -pido que se mida de
   verdad tras desplegar-): blanco sobre "rgb(124, 86, 64)" da ~6.44:1 (fórmula WCAG), SI el
   "color" ahora aplica de verdad; blanco sobre "rgb(99, 69, 51)" (hover) da un ratio aún mayor.
   Si al medir sigue sin ser blanco, el contraste real seguirá siendo el ~1.6:1 que midió
   CENTINEL, y el "!important" de aquí no habría bastado -en ese caso el siguiente paso NO es
   subir a un !important todavía más fuerte (no existe tal cosa), sino averiguar el selector
   exacto que gana, con el navegador delante, en vez de seguir suponiendo-. */
.woocommerce-account .button,
.woocommerce-account .woocommerce-Button,
.woocommerce-account .woocommerce .button,
.woocommerce-account .woocommerce .woocommerce-Button {
	display: inline-block;
	background-color: var(--azr-marron-oscuro);
	color: #fff !important;
	border: none;
	padding: 0.7em 1.4em;
	border-radius: var(--azr-radio);
	text-transform: uppercase;
	letter-spacing: 0.04em;
	font-weight: 600;
	font-size: 0.9em;
	text-decoration: none;
	cursor: pointer;
	transition: background-color 0.15s ease;
}

.woocommerce-account .button:hover,
.woocommerce-account .button:focus,
.woocommerce-account .button:focus-visible,
.woocommerce-account .woocommerce-Button:hover,
.woocommerce-account .woocommerce-Button:focus,
.woocommerce-account .woocommerce-Button:focus-visible,
.woocommerce-account .woocommerce .button:hover,
.woocommerce-account .woocommerce .button:focus,
.woocommerce-account .woocommerce .button:focus-visible,
.woocommerce-account .woocommerce .woocommerce-Button:hover,
.woocommerce-account .woocommerce .woocommerce-Button:focus,
.woocommerce-account .woocommerce .woocommerce-Button:focus-visible {
	background-color: var(--azr-marron-mas-oscuro);
	color: #fff !important;
}

/* Estado desactivado: WCAG excluye explícitamente los controles inactivos del mínimo de
   contraste (1.4.3), así que aquí no se persigue una ratio concreta -solo que se note, a
   simple vista, que no se puede pulsar-. No confirmado en navegador: no he visto ningún botón
   desactivado en las páginas revisadas; se deja preparado por si CENTINEL encuentra uno. */
.woocommerce-account .button:disabled,
.woocommerce-account .button[disabled],
.woocommerce-account .woocommerce-Button:disabled,
.woocommerce-account .woocommerce-Button[disabled],
.woocommerce-account .woocommerce .button:disabled,
.woocommerce-account .woocommerce .button[disabled],
.woocommerce-account .woocommerce .woocommerce-Button:disabled,
.woocommerce-account .woocommerce .woocommerce-Button[disabled] {
	background-color: var(--azr-marron);
	color: #fff !important;
	opacity: 0.6;
	cursor: not-allowed;
}

/* Mismo repaso del "<br>" inyectado (ver "CAUSA REAL (CENTINEL)" en el menú, más arriba):
   los enlaces de acción de pedidos ("Ver", "Pagar", "Cancelar") son "<a>" cortos de una sola
   línea, del mismo tipo que el del menú. No confirmado con HTML real -sin navegador en vivo-,
   se neutraliza igual, sin coste si no hace falta. */
.woocommerce-account .button br,
.woocommerce-account .woocommerce-Button br {
	display: none;
}

/* ================================================================================================
 * 5. TUTOR LMS — escritorio de la plataforma
 * ------------------------------------------------------------------------------------------------
 * HISTORIAL: hasta la v1.2.2 esta sección decía, deliberadamente, "sin reglas": se leyó el código
 * fuente real de Tutor (templates/dashboard.php, templates/dashboard/components/sidebar.php,
 * @since 4.0.0) y no se encontró evidencia de que el escritorio sufriera la misma "ausencia
 * total de estilos" que WooCommerce -Tutor trae su propia hoja de estilos, autosuficiente frente
 * al tema-. Ese criterio era correcto con la evidencia de entonces, y se mantuvo tal cual pide el
 * CREDO del swarm (cero vaguedades: no se corrige lo que no se ha demostrado roto).
 *
 * PRIMERA MEDICIÓN (v1.3.0, 2026-09-05): CENTINEL midió una rotura real, en otro sitio, con otro
 * mecanismo: en /escritorio/account/settings/, las pestañas laterales verticales ("Cuentas
 * sociales", "Notifications", "Preferencias") salían CORTADAS. Sobre el botón de cada pestaña:
 *
 *     letter-spacing ....... 4px       <- ver "ORIGEN REAL" más abajo: NO es de Tutor
 *     text-transform ....... uppercase <- ídem
 *     white-space .......... nowrap    <- no puede partir la palabra
 *     ancho del botón ...... 193px fijo
 *     "Cuentas sociales" necesita 242px -> se corta 49px
 *     "Preferencias" necesita 196px     -> se corta 3px
 *     contenedor ........... overflow "auto hidden" -> recorta lo que sobra
 *
 * Causa del recorte: 4px de espaciado POR CARÁCTER, sobre texto en mayúsculas, es mucho margen
 * ganado en una etiqueta larga (con 16 letras, 64px de más) que el ancho fijo de 193px de Tutor
 * nunca previó. Tutor no está roto: algo ajeno le ensancha el texto por debajo -el mismo patrón de
 * fuga de estilos globales que ya se vio en los botones de WooCommerce (ver "defecto 2/3" más
 * arriba), ahora sobre "letter-spacing"/"text-transform" en vez de sobre "color"-.
 *
 * SEGUNDA MEDICIÓN, TRAS DESPLEGAR v1.3.0 (2026-09-05): la v1.3.0 acotó la corrección a
 * ".tutor-dashboard-layout" -leído en templates/dashboard.php como "el contenedor raíz de TODO el
 * escritorio"-. CENTINEL la desplegó y volvió a medir en la página real: la hoja SÍ carga (el
 * enganche de azr-ui.php funciona bien), pero LA REGLA NO APLICABA. Motivo, medido en el
 * navegador, no deducido de código: ".tutor-dashboard-layout" NO EXISTE en el DOM de
 * /account/settings/ -esa plantilla concreta la pinta otra parte de Tutor, no dashboard.php-.
 * Cadena real de ancestros del botón de pestaña, medida:
 *
 *     button.tutor-tabs-tab
 *       div.tutor-tabs-nav.tutor-profile-settings-tab.tutor-p-5
 *         div.tutor-flex.tutor-gap-8.tutor-my-9
 *           div.tutor-gap-8
 *             div.tutor-account-container
 *               div.tutor-profile-settings-section.tutor-tabs-vertical
 *
 * LECCIÓN (entra en la doctrina de este fichero): que una clase aparezca en una plantilla del
 * plugin NO es prueba de que esté en el DOM de la página que se está corrigiendo -dashboard.php es
 * real, pero /account/settings/ no pasa por ahí-. Se comprueba en la página real, nunca se supone
 * por lectura de código fuente. Corregido: el ancla pasa de ".tutor-dashboard-layout" a
 * ".tutor-account-container" -confirmada presente en la cadena de arriba-, sobre el mismo
 * selector de pestaña de siempre.
 *
 * ORIGEN REAL del espaciado y las mayúsculas (medido por CENTINEL; NO es de Tutor): la tipografía
 * global de Elementor, aplicada a TODOS los botones del sitio, no solo a estas pestañas:
 *
 *     post-7.css -> .elementor-kit-7 button, .elementor-kit-7 input[type="button"], ...
 *                   letter-spacing: var( --e-global-typography-accent-letter-spacing )
 *                   text-transform:  var( --e-global-typography-accent-text-transform )
 *
 * La propia regla de Tutor (tutor-core.min.css: "button.tutor-tabs-tab, .tutor-tabs-tab") pide
 * "text-transform: capitalize" -Tutor NUNCA quiso mayúscula sostenida; se la impone Elementor-.
 * Y esto NO es un problema de especificidad: ".elementor-kit-7 button" es (0,1,1); el ancla
 * anterior, ".tutor-dashboard-layout .tutor-tabs-nav [role=\"tab\"]", ya era (0,3,0) y habría
 * ganado de sobra si hubiera coincidido con algo. Fallaba solo porque no casaba con ningún
 * elemento real -por eso el ancla nueva, con la misma especificidad (0,3,0), tampoco necesita
 * "!important": con un ancla que sí existe, la especificidad ya alcanza-.
 *
 * DECISIÓN DE DISEÑO (sin cambios respecto a v1.3.0, sigue siendo correcta): esto es una lista de
 * pestañas VERTICAL (cada botón ocupa una fila completa de la columna). Dejar que cada botón
 * crezca a su propio ancho haría que las pestañas tuvieran anchos distintos entre sí -una columna
 * dentada, no una lista limpia-, así que la opción correcta para ESTE patrón de UI es dejar el
 * ancho como lo fija Tutor (193px) y permitir que EL TEXTO se parta dentro de él. No depende del
 * idioma ni de la longitud de la etiqueta: cabe en 1 línea si hay sitio, se envuelve a 2 o más si
 * no lo hay, nunca se recorta. Además, se quita el "text-transform: uppercase" -no es una decisión
 * de marca de Tutor (sus etiquetas reales son "Account", "Security", etc., en mayúscula inicial
 * normal, y su propio CSS pide "capitalize", no mayúscula sostenida)-.
 *
 * MEDIDA EXACTA A COMPROBAR (válida para cualquier idioma, no solo para las etiquetas actuales):
 * en cada botón con role="tab" dentro de ".tutor-tabs-nav", "scrollWidth" NO debe ser mayor que
 * "clientWidth", NI "scrollHeight" mayor que "clientHeight" -si son iguales en ambos ejes, no hay
 * nada recortado-. Comprobar en las cinco pestañas de /account/settings/ (Cuenta, Seguridad,
 * Cuentas sociales, Retirar, Preferencias) y, de paso, en las demás pestañas del mismo escritorio
 * si CENTINEL llega a medirlas.
 * NO TOCADO: el texto de las etiquetas ni su idioma; el ancho de 193px que fija Tutor -se ha
 * dejado que el texto se adapte a él, tal como pidió CENTINEL para esta lista vertical-.
 * NO VERIFICADO POR QUIEN ESCRIBE ESTO: no hay navegador en vivo desde aquí; ni el nuevo ancla
 * ".tutor-account-container" ni el efecto sobre "scrollWidth/clientWidth" y
 * "scrollHeight/clientHeight" se han comprobado en el sitio real. Queda para que CENTINEL lo
 * despliegue y lo mida, igual que hizo con las dos rondas anteriores de esta misma sección. */
.tutor-account-container .tutor-tabs-nav [role="tab"] {
	letter-spacing: normal;
	text-transform: none;
	white-space: normal; /* permite partir el texto en vez de recortarlo, sea cual sea su largo */
	overflow: visible; /* por si el recorte medido por CENTINEL ("overflow: auto hidden") está en
	                       el propio botón y no solo en el contenedor: sin esto, aunque el texto
	                       pudiera partirse, seguiría sin verse la segunda línea */
	height: auto; /* si el botón tuviera una altura fija pensada para una sola línea, partir el
	                 texto en dos crearía el mismo recorte en el eje vertical: se deja crecer */
	text-align: left;
}

/* El texto visible vive en un span dentro del botón (settings.php: x-text="tab.label", clase
   "tutor-text-small"); sin esto, el "white-space:normal" del botón no basta si el propio span
   tuviera su "white-space" o su ancho fijados aparte. Mismo ancla que el botón de arriba -la
   confirmada por CENTINEL es ".tutor-account-container", no ".tutor-dashboard-layout"-. */
.tutor-account-container .tutor-tabs-nav [role="tab"] .tutor-text-small,
.tutor-account-container .tutor-tabs-nav [role="tab"] .tutor-text-tiny {
	white-space: normal;
	letter-spacing: normal;
	text-transform: none;
}

/* REVISIÓN PEDIDA POR CENTINEL ("revisa el resto del escritorio con el mismo criterio"), repetida
   tras comprobarse que ".tutor-dashboard-layout" no existe en /account/settings/: el reseteo del
   menú lateral principal (templates/dashboard/components/sidebar.php) llevaba EL MISMO ancla que
   acaba de fallar. El FORGE retiró el ancla sin sustituirla por otra suposición -decisión
   correcta: no tenía forma de comprobarla- y pidió a CENTINEL la medición.

   MEDIDO POR CENTINEL EN EL NAVEGADOR (2026-09-06, pagina "/escritorio/"):
       .tutor-dashboard-sidebar-nav ..... EXISTE, 5 enlaces
       .tutor-dashboard-layout .......... EXISTE tambien AQUI
       enlaces de menu recortados ....... 0
   O sea: la lectura de plantilla del primer FORGE no era falsa, era de OTRA PANTALLA. Las dos
   clases viven en "/escritorio/" y ninguna en "/escritorio/account/settings/", que la pinta una
   plantilla distinta. El selector actual, apoyado solo en la clase propia de Tutor, cubre las dos
   paginas; por eso se deja asi y no se le vuelve a anteponer ".tutor-dashboard-layout", que lo
   dejaria sin efecto justo en la pantalla donde se demostro el problema.

   Aqui el reseteo es PREVENTIVO: hoy no hay ningun enlace recortado en ese menu. Sigue sin llevar
   ningún "!important" ni "white-space" forzado, porque quitar
   espaciado y mayúsculas no puede empeorar nada aunque no hiciera falta. NO se ha revisado el
   resto del escritorio más allá de este menú y las pestañas de "ajustes" -cursos, calificaciones,
   discusiones, intentos de examen quedan sin repasar; si CENTINEL encuentra ahí el mismo patrón,
   la corrección es esta misma, aquí. */
.tutor-dashboard-sidebar-nav a {
	letter-spacing: normal;
	text-transform: none;
}

/* ------------------------------------------------------------------------------------------------
 * 5.1 · COHERENCIA TIPOGRÁFICA — Tutor LMS vs. resto del sitio (FORGE-BRAVO, 2026-09-19)
 * ------------------------------------------------------------------------------------------------
 * ORIGEN DEL HALLAZGO: qa/uat evidencia f1-ux-alumno-20260919/README.md (c)-3 y buyer.json,
 * estilos computados REALES capturados con Playwright (no supuestos de plantilla):
 *
 *     /escritorio/  (Tutor LMS)      body -> font "Inter, -apple-system, BlinkMacSystemFont,
 *                                            \"Segoe UI\", Roboto, sans-serif"
 *                                            color rgb(12,17,29) · bg rgb(250,250,250)
 *                                    button -> font "Mulish, sans-serif" (YA coincide con el
 *                                            tema) · bg rgb(232,174,0) (dorado de marca)
 *
 *     /mi-cuenta/   (WooCommerce, tema)  body -> font "Mulish, sans-serif"
 *                                            color rgb(26,21,18) · bg rgb(250,248,244)
 *                                    h1 -> font "\"Cormorant Garamond\", sans-serif"
 *
 * El botón YA usa Mulish en ambas pantallas (no hay nada que corregir ahí); la fuga real está en
 * el TEXTO DE CUERPO del escritorio de Tutor, que carga "Inter" -una fuente de sistema que el
 * tema del cliente no usa en ningún otro sitio- en vez de "Mulish", y en un fondo/color de texto
 * ligeramente distintos al resto del sitio (gris neutro + azul oscuro, en vez del blanco cálido +
 * marrón oscuro de marca).
 *
 * ANCLAS: ".tutor-dashboard-layout" -confirmada EXISTENTE en el DOM de "/escritorio/" por
 * CENTINEL (ver comentario "MEDIDO POR CENTINEL EN EL NAVEGADOR" arriba, misma sección)- y
 * ".tutor-account-container" -confirmada EXISTENTE en "/escritorio/account/settings/" y
 * subpáginas por el mismo motivo ya documentado en esta sección-. Ambas cubren, entre las dos,
 * todo el escritorio de Tutor visitado en la auditoría (Inicio, Cursos, Notas, Debates, Cuenta,
 * Reseñas, Historial, Ajustes, Lista de deseos, Intentos de examen: todas cuelgan de una de las
 * dos). Sin "!important": son selectores de clase real sobre el contenedor raíz de cada pantalla,
 * que ganan por especificidad frente a la regla de "body" que fija Tutor -no hay otra regla más
 * específica compitiendo por "font-family"/"color"/"background" dentro de este contenedor, a
 * diferencia del caso de los botones de WooCommerce (sección 2), que sí necesitó "!important"
 * porque ahí SÍ había una regla más específica del sitio ganando la cascada-.
 *
 * NO se toca "el dorado de marca" del botón (rgb(232,174,0)): no hay evidencia de que esté mal,
 * y no es lo que reportó la auditoría (c)-3.
 *
 * NO VERIFICADO POR QUIEN ESCRIBE ESTO EN UN NAVEGADOR REAL (no hay navegador en esta máquina):
 * pendiente de que CENTINEL despliegue y mida "getComputedStyle(document.querySelector(sel)).
 * fontFamily/color/backgroundColor" sobre ambas anclas en "/escritorio/" y en
 * "/escritorio/account/settings/", con el mismo método Playwright que generó la evidencia citada
 * arriba, antes de dar esto por cerrado -misma lección de "el arreglo que no entró" que ya paga
 * este fichero en las secciones anteriores. */
.tutor-dashboard-layout,
.tutor-account-container {
	font-family: Mulish, sans-serif;
	color: rgb(26, 21, 18);
	background-color: rgb(250, 248, 244);
}

/* ================================================================================================
 * 6. BOTÓN FLOTANTE DE WHATSAPP — se come un campo del formulario en móvil (FORGE-BRAVO, 2026-09-19)
 * ------------------------------------------------------------------------------------------------
 * ORIGEN (medido, no supuesto): plugin "add-whatsapp-button", fichero
 * wp-content/plugins/add-whatsapp-button/css/awb-styles.css, líneas 9-16:
 *
 *     @media only screen and (max-width: 600px) {
 *         .wab-cont { position: fixed; right: 0; bottom: 10%; z-index: 99999; }
 *     }
 *
 * markup real (plugin.php:203): "<div id=\"wab_cont\" class=\"wab-cont ...\">". "bottom: 10%" mide
 * un 10% de la ALTURA DE VIEWPORT, no de la página: en una pantalla corta como "Pedido recibido"
 * (WooCommerce, la vista con el formulario de login para quien compró sin cuenta), ese 10% cae
 * justo encima del campo de captcha del formulario, tapándolo. Capturado en
 * qa/uat/../f1-compra-gen2-20260919/23b-movil-pedido-recibido.png (390px) y descrito en el README
 * de esa auditoría, hallazgo P2.
 *
 * ALCANCE PEDIDO: solo móvil, solo páginas de acceso/Área de Alumnos. No se toca el plugin (fuera
 * de mi reparto y del repo: vive en wp-content/plugins/, no en este repositorio). Se ancla por
 * CLASE DE BODY de WooCommerce ya usada y confirmada presente en este mismo fichero
 * (".woocommerce-account" se usa más arriba en la sección de botones de Mi Cuenta): WordPress/
 * WooCommerce añaden ".woocommerce-order-received" al body en la página de "Pedido recibido" y
 * ".woocommerce-account" en TODAS las pantallas de "Mi cuenta", incluida la de login. La página
 * "/area-alumnos/" NO tiene una clase de body propia conocida y verificable desde aquí (no es un
 * endpoint de WooCommerce): su ajuste va como CSS en línea condicionado por PHP en azr-ui.php
 * (función "azr_ui_whatsapp_mobile_fix"), no aquí, precisamente para no inventar un selector de
 * body sin confirmar -misma lección de "el arreglo que no entró" de la sección 5-.
 *
 * CORRECCIÓN: se sustituye "bottom: 10%" (relativo a la altura de pantalla, culpable del choque)
 * por un margen fijo pequeño respecto al borde inferior real, igual que la mayoría de widgets
 * flotantes; así el botón queda siempre pegado a la esquina, nunca a mitad de una pantalla corta.
 * Mismo "max-width: 600px" que ya usa el propio plugin, para no tocar el comportamiento en
 * escritorio. Especificidad (0,1,0) sobre la misma clase ".wab-cont" que fija el plugin en su
 * media query -misma especificidad, pero esta regla se encola DESPUÉS (ver "azr_ui_enqueue_styles"
 * en azr-ui.php, prioridad 20) así que gana en la cascada sin necesitar "!important".
 *
 * NO VERIFICADO POR QUIEN ESCRIBE ESTO EN UN NAVEGADOR REAL: pendiente de que CENTINEL despliegue
 * y repita la captura a 390px en "Pedido recibido" sin sesión, comprobando que el botón ya no
 * solapa ningún campo del formulario (bounding box del botón vs. bounding box del campo de
 * contraseña/captcha: cero intersección). */
@media only screen and (max-width: 600px) {
	.woocommerce-order-received .wab-cont,
	.woocommerce-account .wab-cont {
		bottom: 16px;
	}
}

/* ================================================================================================
 * 8. BOTÓN FLOTANTE DE WHATSAPP — OCULTO por completo en /mi-cuenta/ SIN SESIÓN (FORGE-KILO, 2026-09-19)
 * ------------------------------------------------------------------------------------------------
 * BRIEF_FORGE arreglo 5: el reposicionamiento de la sección 6 (bottom:16px) seguía solapando el
 * campo "Nombre de usuario o correo electrónico" en esta pantalla, medido en
 * evidence/f1-e2e-gen3-20260919/README.md (P2 #1, `12a-mi-cuenta-anonimo.png`). Regla nueva y
 * explícita del brief: en las pantallas de acceso (formulario de login visible, sin sesión) el
 * botón se OCULTA por completo -- ya hay ayuda por WhatsApp dentro de la tarjeta de
 * "/area-alumnos/" (azr-student-area-login.php); esta página añade su propio aviso equivalente
 * ("¿Compraste una formación? Entra por el Área de Alumnos",
 * azr_student_area_myaccount_login_notice(), MISMO fichero) justo antes del formulario de Woo.
 *
 * ".woocommerce-form-login" es la clase real de WooCommerce en su propia plantilla
 * (woocommerce/templates/myaccount/form-login.php) para el formulario de acceso -- solo existe en el
 * DOM cuando el visitante NO tiene sesión (my-account.php renderiza el escritorio en su lugar una
 * vez autenticado), así que ":has()" no puede aplicar por error a un alumno ya dentro de su cuenta.
 * Sin ámbito de "max-width": el solape es un problema de layout vertical (el botón cae encima del
 * campo, no depende del ancho), así que se oculta en cualquier tamaño de pantalla -- coherente con
 * el propio texto del brief ("ocúltalo por completo"), no solo el ajuste móvil que ya existía en la
 * sección 6.
 *
 * Soporte de ":has()": Chrome/Edge 105+, Safari 15.4+, Firefox 121+. Degradación segura sin él: el
 * botón queda reposicionado (sección 6), nunca roto.
 * ------------------------------------------------------------------------------------------------
 * NO VERIFICADO POR QUIEN ESCRIBE ESTO EN UN NAVEGADOR REAL: pendiente de que CENTINEL repita la
 * captura sin sesión en "/mi-cuenta/" y confirme que ".wab-cont" ya no aparece en el DOM renderizado. */
body:has(.woocommerce-form-login) .wab-cont {
	display: none !important;
}

/* ================================================================================================
 * 7. SCROLL HORIZONTAL LEVE EN MÓVIL — /escritorio/account/profile/ (FORGE-BRAVO, 2026-09-19)
 * ------------------------------------------------------------------------------------------------
 * ORIGEN: qa/uat/../f1-ux-alumno-20260919/README.md, hallazgo (c)-5: "scrollWidth 412px vs
 * innerWidth 390px (~22px de desbordamiento)" en esa pantalla, a 390px de ancho. La evidencia
 * capturada NO incluye el elemento exacto que desborda (solo el número agregado de
 * document.documentElement) y no hay navegador disponible desde este entorno para localizarlo por
 * inspección en vivo -misma limitación que ya paga este fichero en la sección 5-.
 *
 * DECISIÓN, sin inventar un selector concreto que no se puede confirmar: se limita el ANCHO MÁXIMO
 * del contenedor ya confirmado presente en toda "/escritorio/account/*" (".tutor-account-container",
 * ver sección 5) al ancho real del viewport en móvil, y se evita que cualquier hijo suyo (imagen de
 * perfil, tabla, bloque de texto largo sin espacios) empuje el ancho por encima de eso. Esto no es
 * "arreglar la causa exacta sin verla" -sigue sin identificarse el elemento culpable-, es una cota
 * de seguridad que dejaría el síntoma medido (scrollWidth > innerWidth) en cero pase lo que pase
 * dentro, sin ocultar contenido (solo evita que se salga).
 *
 * NO VERIFICADO POR QUIEN ESCRIBE ESTO EN UN NAVEGADOR REAL: pendiente de que CENTINEL repita la
 * medida de "document.documentElement.scrollWidth" vs "window.innerWidth" a 390px en
 * "/escritorio/account/profile/" tras desplegar esto, y si el desbordamiento persiste, que
 * identifique el elemento exacto con el DOM real -este parche no sustituye esa medición, la acota
 * mientras tanto-. */
@media only screen and (max-width: 600px) {
	.tutor-account-container {
		max-width: 100vw;
		overflow-x: hidden;
	}
	.tutor-account-container img,
	.tutor-account-container table {
		max-width: 100%;
	}
}
