/* PIA — LA BARRA DE SECCIONES DEL TELÉFONO: dónde estoy y adónde puedo ir.
 *
 * Nodo f85ada10, 18-ago-2026. La barra la construye pia-nav-movil.js; aquí se
 * decide dónde vive, cuándo NO existe, y qué controles viejos retira.
 *
 * =============================================================================
 * POR QUÉ ESTE FICHERO NO ES UNA SECCIÓN DE pia-chat-movil.css
 * =============================================================================
 *
 * Por la misma razón por la que aquél no es una sección de pia-movil.css, un
 * piso más arriba. Cada uno de los tres tiene una invariante distinta, y la de
 * éste es la que más lejos llega:
 *
 *   pia-movil.css       adapta LA CAJA de las pantallas de acceso.
 *   pia-chat-movil.css  cambia QUIÉN OCUPA LA PANTALLA dentro de Element.
 *   este fichero        vale FUERA DE ELEMENT.
 *
 * Y ésa es la diferencia dura, no una cuestión de orden: pia-chat-movil.css se
 * carga sólo desde el index.html de Element y todos sus selectores empiezan por
 * una clase `mx_`. Este fichero se carga ADEMÁS desde home.html, tablero.html y
 * ajustes.html, que no tienen ni una sola clase de Element. Meter estas reglas
 * allí sería escribir CSS que no puede aplicarse en tres de las cuatro
 * pantallas para las que se escribió.
 *
 * =============================================================================
 * LOS TRES ESTADOS, Y EL DE EN MEDIO ES EL QUE PIDIÓ ZEY
 * =============================================================================
 *
 *   pantalla de sección   (Inicio · Chats · Tablero · Ajustes)   LA BARRA SE VE
 *   dentro de una sala    (.mx_RoomView en el DOM)               NO EXISTE
 *   pantalla de acceso    (.mx_AuthPage en el DOM)               NO EXISTE
 *
 * El segundo es el encargo textual: «que NO debe estar disponible dentro de un
 * chat/grupo abierto». Y no es una manía de Zey, es el patrón: ni WhatsApp ni
 * Telegram enseñan su barra de secciones dentro de una conversación. Una
 * conversación en un teléfono es pantalla completa, y una barra de secciones
 * ahí abajo compite por el borde con el compositor, que es lo único que
 * importa en esa pantalla.
 *
 * EL TERCERO NO ESTABA EN EL ENCARGO Y ES OBLIGATORIO IGUAL. pia-lanzador.js
 * tiene la cicatriz escrita: un botón suyo salió una vez en el login, encima de
 * la tarjeta de «Iniciar sesión», ofreciéndole los ajustes a quien todavía no
 * había entrado. Esta barra ofrece CUATRO destinos y tres de ellos leen datos
 * de la cuenta. Se esconde en `.mx_AuthPage` desde la primera versión, y no
 * después de que alguien lo vea.
 *
 * LA SEÑAL ES EL DOM Y NO EL HASH, y está medida por 3c1a9f62, no supuesta:
 * `.mx_RoomView` no existe en #/home y sí existe en #/room/…. Se reusa esa
 * misma señal a propósito. Si algún día cambia, la pantalla que se ve y esta
 * barra cambian JUNTAS, porque es una condición escrita dos veces y no dos
 * criterios que hoy coinciden por casualidad.
 *
 * =============================================================================
 * QUIÉN MANDA EN EL BORDE DE ABAJO
 * =============================================================================
 *
 * Acordado con quien lleva home.html (nodo 42ec6bc8), porque ahí hay un
 * compositor `sticky bottom: 0` y dos cosas ancladas al mismo borde se pisan
 * por definición, no por un bug.
 *
 * MANDA LA BARRA, Y TODO LO DEMÁS SE APILA ENCIMA. No es preferencia: una barra
 * de secciones tiene que estar a la MISMA altura en todas las secciones. Una
 * barra que en Inicio está a 121px del borde y en Chats a 0 no es una barra de
 * pestañas, es una barra que se mueve al navegar, y entonces hay que mirar
 * dónde está antes de apuntar. Además es lo que hacen las dos plataformas: la
 * barra de pestañas es el cromo más exterior y los mini-reproductores, los
 * compositores y los avisos se apilan SOBRE ella, nunca debajo.
 *
 * De ahí sale `--pia-alto-nav`, que se declara UNA vez aquí y la consume
 * home.html. No se le pasa a nadie un 56 para que lo vuelva a teclear: es la
 * lección de §10bis —un valor que se describe sin nombrarlo se re-teclea en
 * cada sitio y deriva—, aplicada entre dos ficheros de dos nodos distintos.
 *
 * Y SE DECLARA DENTRO DEL @media A PROPÓSITO. Por encima de 480px la barra no
 * existe, así que la variable tampoco: quien la consuma con `var(--pia-alto-nav,
 * 0px)` recibe 0 en escritorio sin tener que escribir una segunda regla ni
 * repetir el punto de corte. El punto de corte se declara UNA vez, aquí, y el
 * resto lo hereda por la puerta de atrás del valor por defecto.
 *
 * =============================================================================
 * N0 · EL BORDE DE ABAJO EN ANDROID LO PUBLICA LA ACTIVITY, Y `viewport-fit`
 *      NO LO RESUELVE — MEDIDO, nodos 0b04af15 y e0e592ea, 18-ago-2026
 * =============================================================================
 *
 * AQUÍ HABÍA UNA HIPÓTESIS RAZONABLE Y RESULTÓ SER FALSA. Decía que
 * `env(safe-area-inset-bottom)` devuelve 0 sólo porque ninguna pantalla declara
 * `viewport-fit=cover`, y que declarándolo «la barra sube ella sola». Se fue a
 * comprobar y NO: en Android el inset de abajo sigue valiendo 0 CON cover.
 *
 * LA MEDICIÓN, en el emulador PIA_API36 (SDK 36, gestos), sobre la WebView viva
 * de `com.pia.app` y con `viewport-fit=cover` HORNEADO en el HTML servido —no
 * inyectado por JS, que es un experimento que no vale porque el navegador no
 * reevalúa `viewport-fit` al cambiar el meta en caliente:
 *
 *     sin cover  →  inset-bottom 0px   inset-top 49px
 *     con cover  →  inset-bottom 0px   inset-top 49px      <-- no se movió
 *
 * POR QUÉ, y es lo que hay que saberse: en Android `env(safe-area-inset-*)`
 * refleja el RECORTE DE PANTALLA (display cutout), NO las barras del sistema.
 * En iOS refleja las dos cosas, y de ahí viene la confusión. Los números del
 * `dumpsys window` de ese mismo emulador lo dejan sin discusión:
 *
 *     displayCutout    top    128px físicos  → 128/2.625 = 49 CSS px  ✔ reportado
 *     navigationBars   bottom  63px físicos  →  63/2.625 = 24 CSS px  ✘ NO reportado
 *
 * O sea que hay 24 CSS px reales de barra de gestos que la página no ve, y no
 * los verá por declarar nada en el `<meta>`: en una WebView el modo de recorte
 * lo decide la Activity anfitriona, no el documento.
 *
 * Y EL PROBLEMA DE FONDO SÍ ES REAL: `innerHeight` (915) == `screen.height`
 * (915), o sea que la WebView ocupa la pantalla ENTERA y lo anclado abajo se
 * dibuja debajo de la barra de gestos. Hay captura en el nodo: una franja roja
 * en `bottom: 0` con `padding-bottom: env(...)` sale con el pill de gestos
 * pintado ENCIMA, sin apartarse un píxel.
 *
 * LO QUE DE VERDAD LO ARREGLA EN ANDROID es nativo, no CSS, y YA ESTÁ HECHO
 * (nodo e0e592ea): `MainActivity` lee los `WindowInsets` y publica cuatro
 * variables en el `documentElement` —`--pia-inset-arriba/abajo/izq/der`—, que
 * es lo que consume `--pia-hueco-abajo` en N1. NO lo intentes otra vez desde el
 * `<meta>`: desde ahí no se puede. Y si el hueco vuelve a valer 0 en Android, lo
 * primero que hay que comprobar NO es este fichero sino que el APK instalado
 * lleve ese MainActivity — la sonda imprime la variable justo para eso.
 *
 * QUÉ SE QUEDA, ENTONCES, Y POR QUÉ: las tres pantallas sueltas SÍ declaran ya
 * `viewport-fit=cover`, porque en iOS —donde `safe-area` sí mapea las barras—
 * es la diferencia entre pantalla completa y letterbox, y la concha de iOS carga
 * ESTAS MISMAS páginas desde el contenedor de Element. Este fichero consume
 * `env(safe-area-inset-bottom, 0px)` y en Android suma 0 sin romper nada.
 *
 * PARA VOLVER A MEDIRLO, sin adivinar:
 *     node scripts/sonda-safearea-movil.mjs
 * Imprime el inset Y EL TEXTO DEL `<meta>` que tiene la página cargada. Ese
 * segundo dato es el que distingue «el arreglo no sirve» de «estás mirando la
 * imagen vieja», que es como se le apunta a alguien un arreglo como fallido.
 */

@media (max-width: 480px) {

  /* =========================================================================
   * N1 · EL TAMAÑO, DECLARADO UNA VEZ
   * ========================================================================= */
  :root {
    /* EL HUECO DEL SISTEMA DE ABAJO, DE UNA SOLA FUENTE Y CON LAS DOS VÍAS.
     *
     * `--pia-inset-abajo` la publica la Activity nativa de Android leyendo los
     * `WindowInsets` de verdad (MainActivity.java, nodo e0e592ea) — allí es la
     * ÚNICA vía, porque `env(safe-area-inset-bottom)` sólo refleja el recorte de
     * pantalla y la barra de gestos no es un recorte (N0, aquí arriba: 24 CSS px
     * medidos que el CSS no ve). En iOS no la publica nadie y se cae al `env()`,
     * que allí sí mapea las barras. Una sola declaración, sin segunda regla y
     * sin preguntar por la plataforma.
     *
     * SE CONSUME ESTA Y NO `--pia-inset-abajo` A PELO para que el fallback esté
     * escrito UNA vez: el día que alguien añada un tercer consumidor no tiene
     * que acordarse de repetir el `env()` detrás. */
    --pia-hueco-abajo: var(--pia-inset-abajo, env(safe-area-inset-bottom, 0px));

    /* 56px es el alto de la barra SIN contar el hueco del sistema. Es el número
     * de Android (56dp) y no el de iOS (49pt) porque aquí hay ICONO Y RÓTULO en
     * dos líneas: con 49 el rótulo queda a 3px del borde y se lee pegado. Y
     * queda cómodamente por encima del suelo de toque de §10 M5, que son 44. */
    --pia-alto-nav: 56px;

    /* La píldora FLOTA: éste es el aire que le queda por debajo y por los lados
     * (los lados usan --pia-margen-lienzo, que es el del resto del producto). */
    --pia-nav-aire: 12px;

    /* El botón de PIA: diámetro y cuánto SOBRESALE por encima de la píldora. La
     * elevación es lo que Zey señaló de su referencia, así que es una medida de
     * diseño y no un ajuste fino: 18 de 60 deja fuera algo menos de un tercio
     * del círculo, que es donde se lee como «encajado» y no como «pegado». */
    --pia-nav-pia: 60px;
    --pia-nav-elevacion: 18px;

    /* EL RADIO DE LA MUESCA SALE DEL DIÁMETRO DEL BOTÓN, no se teclea. Es el
     * radio del círculo (30) más 5 de holgura, para que se vea aire alrededor y
     * no un encaje a presión. Escribir «35px» a mano aquí sería exactamente la
     * deriva de §10bis: el día que alguien cambie --pia-nav-pia, la muesca se
     * quedaría con el tamaño del botón viejo y el círculo pisaría el recorte,
     * sin dar ningún error. */
    --pia-nav-muesca: calc(var(--pia-nav-pia) / 2 + 5px);

    /* LO QUE DE VERDAD OCUPA LA BARRA, de una vez y contando TODO: la parte del
     * botón que sobresale, la píldora y el aire de abajo. Es ESTE el que consumen
     * las reglas que reservan sitio y el que consume home.html para subir su
     * compositor.
     *
     * SE INCLUYE LA ELEVACIÓN AUNQUE SÓLO LA OCUPE EL TERCIO CENTRAL. La
     * referencia deja el círculo flotando sobre el contenido, y podría
     * defenderse no reservarlo; pero entonces la última línea de la lista pasa
     * por debajo del botón de PIA justo en el centro de la pantalla, que es
     * donde se está mirando. Se prefiere gastar 18px de más a que el contenido
     * se pierda detrás del control más grande de la barra.
     *
     * Y ESTA CUENTA YA SE EQUIVOCÓ UNA VEZ, en su versión plana: la barra medía
     * 57px (56 + un borde de 1) y aquí se reservaban 56, así que un píxel de la
     * última fila quedaba debajo. Se detectó comparando el alto MEDIDO con el
     * declarado, no mirando una captura. Por eso la sonda compara los dos. */
    --pia-alto-nav-total: calc(
      var(--pia-nav-elevacion) + var(--pia-alto-nav) + var(--pia-nav-aire)
      + var(--pia-hueco-abajo)
    );
  }

  /* =========================================================================
   * N2 · LA BARRA
   * ========================================================================= */
  .pia-nav {
    position: fixed;
    /* PÍLDORA FLOTANTE, no una franja pegada al borde. Es la forma que pidió
     * Zey con su referencia (whiteboard 18e86995). El margen lateral es el del
     * lienzo, así que la barra se alinea con las tarjetas del Home y con el
     * texto de la lista en vez de tener un aire propio inventado. */
    left: var(--pia-margen-lienzo);
    right: var(--pia-margen-lienzo);
    bottom: calc(var(--pia-nav-aire) + var(--pia-hueco-abajo));

    /* GRID DE CUATRO COLUMNAS IGUALES, y no un flex con `flex: 1`.
     *
     * Con `grid-template-columns: repeat(4, 1fr)` las cuatro pestañas miden
     * EXACTAMENTE lo mismo pase lo que pase con su rótulo. Con flex, «Tablero»
     * (7 letras) reclamaría más base que «Chats» (5) y las cuatro dianas
     * quedarían de anchos distintos — invisible en una captura y muy visible con
     * el pulgar, porque la frontera entre pestañas deja de estar donde el ojo
     * la pone. `1fr` en una rejilla ignora el contenido; en flex hay que ir a
     * pelearse con `flex-basis: 0` y `min-width: 0` para conseguir lo mismo.
     *
     * Y el `minmax(0, 1fr)` es la mitad que se olvida (§10 M6, en su forma de
     * rejilla): sin él una pista tiene mínimo `auto` —el min-content de su
     * contenido— y un rótulo largo ensancharía su columna igualmente. */
    /* EL NÚMERO DE COLUMNAS LO PONE EL JS, no está tecleado aquí. Es la misma
     * variable con la que se coloca la muesca, así que la rejilla y el recorte
     * no pueden decir cosas distintas. El `3` del final es sólo el valor por
     * defecto si el <script> no llegara a correr. */
    /* DÓNDE CAE EL CENTRO DEL BOTÓN DE PIA, en % del ancho de la barra, y ESTA
     * DECLARACIÓN TIENE QUE VIVIR AQUÍ Y NO EN `:root`. Estuvo en `:root` y no
     * funcionaba, en silencio y con la forma correcta.
     *
     * Una propiedad personalizada resuelve sus `var()` EN EL ELEMENTO DONDE SE
     * DECLARA, no donde se usa. Las dos variables de dentro las escribe el JS
     * sobre `.pia-nav` (nº de columnas e índice de la marcada `centro: true`),
     * así que en `:root` no existían y el `calc` se quedaba con los valores por
     * defecto: `(1 + .5) / 3`, o sea 50%, pasara lo que pasara con la lista.
     *
     * CÓMO SE VIO, porque no se ve mirando: con cuatro pestañas el botón de PIA
     * cae en x=150 y el recorte se quedaba en el 50% (x=179). 29px de desajuste
     * — suficiente para que el círculo pise el borde de la píldora y NO tanto
     * como para cantar en una captura. Salió de leer `--pia-nav-centro-x`
     * computada y compararla con el centro real del botón, que es justo el par
     * de números que una captura no da. */
    --pia-nav-centro-x: calc(
      (var(--pia-nav-centro-i, 1) + .5) / var(--pia-nav-columnas, 3) * 100%
    );

    display: grid;
    grid-template-columns: repeat(var(--pia-nav-columnas, 3), minmax(0, 1fr));

    height: var(--pia-alto-nav);
    /* AQUÍ HABÍA UN `padding-bottom: env(safe-area-inset-bottom, 0px)` Y ERA EL
     * MISMO HUECO CONTADO DOS VECES (nodo 0b04af15).
     *
     * Su comentario razonaba sobre una barra PEGADA al borde, que es lo que esta
     * barra era antes de volverse píldora flotante: entonces sí, el hueco del
     * sistema había que dejarlo dentro. Pero desde que `bottom` vale
     * `calc(var(--pia-nav-aire) + env(safe-area-inset-bottom, 0px))` (N2, arriba)
     * la píldora YA está levantada por encima de la barra de gestos, y este
     * padding le añadía el hueco OTRA VEZ por dentro. Y no era invisible: el
     * `::before` que pinta la píldora es `position:absolute; inset:0`, así que
     * cubre también el padding — la píldora se dibujaba `inset` px más alta.
     *
     * NO SE VEÍA PORQUE `env(...)` VALÍA 0 EN TODAS PARTES, que es justo lo que
     * este nodo vino a cambiar. Con el inset a 0 las dos formas dan el mismo
     * píxel; el día que reporte 34pt en un iPhone, la de antes subía la barra 34
     * Y la engordaba 34.
     *
     * LA CUENTA QUE LO CIERRA: lo que la barra ocupa desde el borde inferior es
     * ahora `aire + inset + alto-nav + elevacion`, que es exactamente
     * `--pia-alto-nav-total` (N1). Con el padding puesto sobraba un `inset`, y el
     * contenido reservaba menos de lo que la barra tapaba. */
    box-sizing: content-box;

    /* EL FONDO NO VA AQUÍ SINO EN EL ::before, y no es un capricho: la píldora
     * necesita una MUESCA circular arriba en el centro para que el botón de PIA
     * se encaje en ella, y la muesca se hace con `mask`. Una máscara recorta
     * también a los HIJOS, así que si el fondo viviera en `.pia-nav` la máscara
     * se comería el propio botón central y media pestaña de al lado. Poniendo el
     * fondo en una capa aparte, la máscara sólo muerde a esa capa. */
    background: none;

    /* 900, EL MISMO DE `.pia-lanzador`, Y ES DELIBERADO. Está por encima del
     * lienzo de la app y POR DEBAJO de los diálogos de Element (medidos por
     * pia-lanzador.js: `mx_Dialog_wrapper` a 4000 y su fondo a 4009). Una barra
     * de secciones flotando sobre un diálogo abierto sería un control que
     * invita a irte de una pantalla que te está preguntando algo. */
    z-index: 900;
  }

  /* N2bis · LA PÍLDORA Y SU MUESCA.
   *
   * Capa de fondo aparte (ver arriba). Es OPACA, no translúcida: debajo pasa una
   * lista de chats con avatares de colores, y con transparencia el contraste de
   * los rótulos cambiaría a cada scroll.
   *
   * LA MUESCA ES UN `mask` CON UN GRADIENTE RADIAL, y es la única forma que
   * funciona aquí. Las alternativas y por qué no:
   *   · Un círculo del color del fondo encima («goma de borrar»): NO. Debajo de
   *     la barra no hay un color plano, hay la lista scrolleando. Una goma
   *     blanca taparía contenido en vez de dejar ver a través.
   *   · Un SVG de fondo con el recorte ya hecho: funciona, pero mete la
   *     geometría en un fichero binario donde nadie la puede ajustar, y el radio
   *     tendría que estar escrito dos veces (en el SVG y en el botón).
   * Con la máscara, el radio sale de la MISMA variable que el botón, así que no
   * pueden derivar. El +3px del hueco es la holgura para que se vea el aire
   * alrededor del círculo y no un encaje a presión. */
  .pia-nav::before {
    content: "";
    position: absolute;
    inset: 0;
    /* DEBAJO DE LAS PESTAÑAS, Y ESTO ARREGLA UN FALLO QUE YA PASÓ: sin el
     * `z-index: -1`, esta capa TAPABA LOS ICONOS. Un `::before` posicionado se
     * pinta en la capa de los elementos posicionados, o sea POR ENCIMA de los
     * hijos en flujo normal —que es lo que son los enlaces de la barra—, así que
     * la píldora blanca se pintaba sobre ellos. En la captura sólo se veían el
     * botón de PIA y el punto de la activa (los dos SÍ posicionados: uno por su
     * `transform`, el otro por ser absoluto), y el resultado parecía «los iconos
     * no se generan» cuando estaban perfectamente pintados debajo de una capa
     * blanca. Se ve mirando la captura; no se ve leyendo la regla. */
    z-index: -1;
    background: var(--pia-fondo);
    border-radius: 999px;
    /* La sombra hace el trabajo que hacía el borde superior cuando la barra
     * estaba pegada al borde: decir «esto flota por encima, no es parte de la
     * lista». Va suave y baja, no un halo. */
    /* EL BORDE ES OBLIGATORIO AQUÍ Y EN LA REFERENCIA NO LO ERA. En la imagen
     * que pasó Zey la píldora es blanca sobre un lienzo GRIS, así que su silueta
     * la dibuja el contraste con el fondo. El lienzo de PIA es BLANCO
     * (--pia-fondo), o sea que una píldora blanca sobre él no tiene silueta: en
     * la primera captura sólo se distinguían sus dos extremos redondeados y por
     * la sombra. Con el mismo separador que usa el resto del producto vuelve a
     * ser un objeto y no una mancha, sin inventar un gris de fondo que no está
     * en el sistema. */
    border: 1px solid var(--pia-borde);
    box-shadow: 0 4px 18px rgba(20, 20, 20, .16);
    /* EL CENTRO DEL RECORTE SE CALCULA, NO SE ESCRIBE `50%`. Cae en el medio de
     * la columna del botón de PIA: (i + 0,5) / columnas. Con `50%` fijo el
     * recorte sólo acierta si PIA está en el centro exacto, o sea con un número
     * impar de pestañas y ella justo en medio — que hoy NO es el caso mientras
     * Ajustes siga en la barra esperando su puerta en el Home. */
    -webkit-mask: radial-gradient(circle var(--pia-nav-muesca) at var(--pia-nav-centro-x) 0,
                  transparent calc(var(--pia-nav-muesca) - 1px), #000 var(--pia-nav-muesca));
            mask: radial-gradient(circle var(--pia-nav-muesca) at var(--pia-nav-centro-x) 0,
                  transparent calc(var(--pia-nav-muesca) - 1px), #000 var(--pia-nav-muesca));
  }

  /* =========================================================================
   * N3 · CADA PESTAÑA
   * ========================================================================= */
  .pia-nav__seccion {
    display: flex;
    flex-direction: column;
    align-items: center;
    justify-content: center;
    gap: 2px;

    /* La diana es TODA la celda —97px de ancho a 390px por los 56 de alto—, muy
     * por encima de los 44 de §10 M5. Se consigue con `display:flex` en el
     * propio <a> y no con un padding a ojo: así la zona pulsable es la columna
     * entera y no queda ni un píxel muerto entre dos pestañas, que es donde
     * cae el dedo cuando alguien apunta a la frontera. */
    height: 100%;
    min-width: 0;
    /* ANCLA DE SUS DOS HIJOS ABSOLUTOS: el rótulo escondido y el punto de la
     * activa. Sin esto los dos se colgarían de `.pia-nav`, que es el primer
     * antepasado posicionado, y el punto aparecería en una esquina de la barra
     * en vez de bajo SU pestaña. Pasó, y en la captura se leía como «el punto
     * está en la pestaña equivocada». */
    position: relative;

    text-decoration: none;
    color: var(--pia-texto-tercero);       /* 4.88:1 sobre el fondo · AA */
    -webkit-tap-highlight-color: transparent;
  }

  .pia-nav__icono {
    display: flex;
    /* Los SVG vienen a 24x24 y aquí se fijan: si un icono futuro llegara a otro
     * tamaño, las cuatro pestañas dejarían de alinearse en vertical y sería de
     * esas cosas que sólo se ven poniendo dos capturas una al lado de la otra. */
    width: 24px;
    height: 24px;
  }
  .pia-nav__icono > svg { width: 100%; height: 100%; display: block; }

  /* EL RÓTULO EXISTE PERO NO SE PINTA, y este cambio de opinión hay que dejarlo
   * escrito porque la versión anterior de este fichero defendía lo contrario.
   *
   * LA PRIMERA VERSIÓN ROTULABA LAS CUATRO PESTAÑAS, con el argumento de que
   * «Tablero» es un concepto de PIA sin icono universal y que Telegram, WhatsApp
   * y Element X rotulan las suyas. Sigue siendo verdad de una barra de cuatro o
   * cinco. Dejó de aplicar por dos cosas que pasaron después:
   *
   *   · La referencia que dio Zey es SIN rótulos, con un punto para la activa, y
   *     lo que dijo es que le gusta «este tipo de nav bars». El rótulo no es un
   *     detalle de color o de icono —lo que pidió ignorar—, es la forma.
   *   · Y quedaron TRES pestañas, no cuatro. El riesgo de un icono mudo crece
   *     con el número: con tres, y siendo una el botón de marca (que además es
   *     el sitio donde ya estás la mitad de las veces), lo que hay que adivinar
   *     son dos dibujos, no cuatro.
   *
   * Y NO SE BORRA EL TEXTO, SE ESCONDE. El nombre accesible del enlace tiene que
   * seguir saliendo de texto real: quien navegue con lector de pantalla oye
   * «Chats, enlace» igual que antes. Borrar el <span> y fiarlo todo a un
   * `aria-label` habría dado el mismo resultado hoy y una pestaña muda el día que
   * alguien olvide el atributo en una sección nueva.
   *
   * Se esconde con la receta de siempre (1px + clip) y NO con `display: none`
   * ni `visibility: hidden`, que sacan el texto del árbol de accesibilidad — o
   * sea que dejarían los enlaces sin nombre, que es peor que no tener rótulo. */
  .pia-nav__etiqueta {
    position: absolute;
    width: 1px;
    height: 1px;
    margin: -1px;
    padding: 0;
    overflow: hidden;
    clip-path: inset(50%);
    white-space: nowrap;
    border: 0;
  }

  /* EL PUNTO DE LA SECCIÓN ACTIVA — el indicador de la referencia.
   *
   * Sustituye al peso de la tipografía que usaba la versión rotulada: sin
   * rótulo no hay peso que cambiar, así que el segundo canal (además del color)
   * pasa a ser la PRESENCIA de una marca. Y presencia/ausencia es un canal más
   * fuerte que un cambio de tono, no más débil: no depende de distinguir dos
   * grises.
   *
   * Va en un `::after` y no en un elemento del JS: es decoración pura, no tiene
   * que existir para un lector de pantalla —eso ya lo dice `aria-current`— y así
   * el marcado no lleva un <span> vacío cuyo único trabajo es pintar 5px. */
  .pia-nav__seccion[aria-current="page"]::after {
    content: "";
    position: absolute;
    bottom: 9px;
    width: 5px;
    height: 5px;
    border-radius: 50%;
    background: currentColor;
  }

  /* LA PESTAÑA ACTIVA, POR DOS CANALES Y NO SÓLO POR COLOR.
   *
   * El color hace el trabajo (gris 4.88:1 → tinta 18.42:1, que es un salto
   * enorme), pero el color solo deja fuera a quien no lo distingue, y aquí no
   * hace falta gastar nada para añadir el segundo canal: el peso. Es lo mismo
   * que hace la regla de pigmento del canvas —lo excepcional destaca— con la
   * diferencia de que aquí lo excepcional es exactamente UNA de cuatro filas
   * siempre, por construcción.
   *
   * EL GANCHO ES `[aria-current="page"]` Y NO UNA CLASE. El estado se declara
   * una sola vez en el JS, en el atributo que además ya significa esto para un
   * lector de pantalla. Con una clase propia habría dos fuentes de verdad para
   * el mismo estado y el día que una se quedara vieja, lo que se ve y lo que se
   * anuncia dirían cosas distintas. */
  .pia-nav__seccion[aria-current="page"] {
    color: var(--pia-accion);
  }

  /* =========================================================================
   * N7 · EL BOTÓN DE PIA: CÍRCULO DE TINTA, ELEVADO
   * =========================================================================
   *
   * Es la pieza que Zey pidió por su nombre. Se encaja en la muesca que abre
   * §N2bis, y las dos salen de la MISMA variable de diámetro, así que no pueden
   * desalinearse.
   *
   * LLEVA COLOR SIEMPRE, ESTÉ ACTIVA O NO, y es la excepción a la regla de
   * pigmento de esta casa —donde el color marca lo que pide una acción, no lo
   * normal—. Aquí el círculo de tinta no dice «estás en PIA»: dice «esto es
   * PIA», que es identidad y no estado. Por eso el estado sigue diciéndolo el
   * punto de §N3, también en este botón: si el color hiciera las dos cosas, no
   * habría forma de saber si estás dentro o fuera de la pantalla de PIA. */
  .pia-nav__seccion--pia {
    /* Se sale de su celda hacia arriba. `align-self: start` + un translate
     * negativo, y no `position: absolute`, para que siga ocupando su columna en
     * la rejilla: absoluto lo sacaría del reparto y las otras dos pestañas se
     * repartirían el ancho entero, dejando el círculo descentrado respecto a la
     * muesca. */
    align-self: start;
    justify-self: center;
    width: var(--pia-nav-pia);
    height: var(--pia-nav-pia);
    transform: translateY(calc(var(--pia-nav-elevacion) * -1));
    border-radius: 50%;
    background: var(--pia-accion);
    color: var(--pia-accion-texto);      /* 18.42:1 sobre la acción */
    box-shadow: 0 3px 10px rgba(20, 20, 20, .22);
  }

  /* El círculo NO cambia de color al ser la sección activa —ya es de color—, así
   * que se le fuerza el suyo por encima de la regla de `[aria-current]`, que
   * pintaría el glifo de tinta sobre tinta y lo dejaría invisible. Es
   * exactamente el fallo que se busca cuando un estado y una identidad usan el
   * mismo canal. */
  .pia-nav__seccion--pia[aria-current="page"] {
    color: var(--pia-accion-texto);
  }

  /* Y su punto de activa va POR DEBAJO del círculo, ya dentro de la píldora —es
   * donde lo pone la referencia—, no encima del glifo blanco. */
  .pia-nav__seccion--pia[aria-current="page"]::after {
    bottom: calc(var(--pia-nav-elevacion) * -1 + 9px);
    background: var(--pia-accion);
  }

  /* El foco visible es el de la casa. No se quita nunca: estos son enlaces y se
   * puede llegar a ellos con un teclado bluetooth, que en una tableta con
   * teclado es lo normal y no una rareza. */
  .pia-nav__seccion:focus-visible {
    outline: 2px solid var(--pia-accion);
    outline-offset: -3px;
    border-radius: var(--pia-radio-campo);
  }

  /* =========================================================================
   * N4 · DÓNDE NO EXISTE
   * ========================================================================= */

  /* N4.1 · Dentro de una sala. ES EL ENCARGO. */
  body:has(.mx_RoomView) .pia-nav { display: none; }

  /* N4.2 · En la pantalla de acceso, por la cicatriz de pia-lanzador.js. */
  body:has(.mx_AuthPage) .pia-nav { display: none; }

  /* =========================================================================
   * N5 · Y EL SITIO QUE HAY QUE RESERVARLE
   * =========================================================================
   *
   * Una barra `fixed` no ocupa sitio en el flujo: si nadie le reserva su alto,
   * se pinta ENCIMA de lo último de la pantalla. Y «lo último» aquí es la última
   * conversación de la lista y la última tarjeta del Home — o sea, contenido, no
   * relleno. Es un desborde que no se ve, porque lo que se pierde queda tapado
   * por algo que sí está bien pintado.
   *
   * SON DOS REGLAS Y NO UNA PORQUE SON DOS MUNDOS DISTINTOS: en Element el
   * documento no scrollea (la app ocupa el 100% y scrollean sus paneles), así
   * que un `padding-bottom` en el <body> no haría nada; en las páginas sueltas
   * el documento sí scrollea y el padding es exactamente la herramienta.
   */

  /* N5.1 · EN ELEMENT: la app se queda más baja.
   *
   * `!important` es obligatorio y es la única razón por la que está aquí. Este
   * contenedor lleva EN LÍNEA `style="height:100%; width:100%; overflow:hidden;
   * display:flex; …"` (lo dejó medido pia-chat-movil.css), y una declaración en
   * línea gana a cualquier hoja de autor por especificidad, esté en la capa que
   * esté. La única cosa del lenguaje que le gana es un `!important` de autor,
   * porque la importancia se resuelve ANTES que la especificidad.
   *
   * VA CONDICIONADO A QUE LA BARRA SE VEA. Dentro de una sala la barra no
   * existe, y una app 56px más baja con nada debajo dejaría una franja blanca
   * bajo el compositor de Element — el hueco de una barra que no está. */
  body:not(:has(.mx_RoomView)):not(:has(.mx_AuthPage)) .mx_MatrixChat > div {
    height: calc(100% - var(--pia-alto-nav-total)) !important;
  }

  /* N5.2 · EN LAS PÁGINAS SUELTAS: el documento acaba más arriba.
   *
   * `body:not(:has(.mx_MatrixChat))` es «esto no es Element», y se pregunta por
   * la app y no por la ruta a propósito: la ruta la sabe el servidor y aquí sólo
   * hay DOM. Es el mismo criterio que N4 —preguntarle al DOM qué hay montado— y
   * no un segundo criterio que hoy coincide.
   *
   * NO RESUELVE EL COMPOSITOR DE home.html Y NO PRETENDE HACERLO: un padding al
   * final del documento despeja lo que hay al FINAL del scroll, y el compositor
   * de Home es `sticky bottom: 0`, o sea que está aparcado en el borde desde el
   * primer píxel. Eso se arregla en home.html subiéndolo `--pia-alto-nav`, que
   * es lo acordado con 42ec6bc8 y por eso esta variable es pública. */
  body:not(:has(.mx_MatrixChat)) {
    padding-bottom: var(--pia-alto-nav-total);
  }

  /* =========================================================================
   * N6 · LOS TRES CONTROLES QUE ESTA BARRA JUBILA
   * =========================================================================
   *
   * ESTA ES LA MITAD QUE HACE QUE ESTO NO SEA «UN CONTROL MÁS». Los tres
   * destinos que la barra rotula ya existían en el teléfono como botones
   * flotantes sin rótulo, repartidos en dos esquinas por encima de la lista.
   * Dejarlos puestos sería enseñar la misma navegación dos veces con dos
   * lenguajes distintos, y la barra habría AÑADIDO cromo en vez de ordenarlo.
   *
   * Se esconden aquí y no en pia-chat-movil.css porque la razón por la que se
   * van es ÉSTA barra: el día que alguien borre este fichero, los tres botones
   * tienen que volver solos. Si la regla viviera en el otro, borrar la barra
   * dejaría el teléfono sin ninguna de las dos cosas.
   *
   * `#pia-volver-lista` NO ESTÁ EN ESTA LISTA, y es la distinción entera: los
   * otros tres son NAVEGACIÓN ENTRE SECCIONES —lo que la barra hace— y ése es
   * la SALIDA DE UNA SALA, que es donde la barra no existe. Se llaman parecido y
   * llevan clases parecidas; hacen cosas distintas en pantallas distintas. */
  #pia-volver-inicio,
  #pia-lanzador-tablero,
  #pia-lanzador-ajustes {
    display: none;
  }
}

/* =============================================================================
 * Y POR ENCIMA DE 480px LA BARRA NO EXISTE.
 * =============================================================================
 *
 * En escritorio la lista está siempre a la vista, el raíl de espacios es una
 * columna y los lanzadores de PIA están en su escalera: la navegación ya está
 * resuelta y una barra abajo sería una quinta forma de llegar a lo mismo.
 *
 * VA FUERA DEL @media Y EN NEGATIVO, no dentro del de arriba en positivo, y es
 * la misma lección que pia-chat-movil.css dejó escrita sobre `.pia-volver`: la
 * barra la pinta un <script> que corre en TODOS los anchos. Si la regla que la
 * esconde viviera dentro del `@media (max-width: 480px)`, en escritorio no
 * habría NINGUNA regla escondiéndola y saldría una barra de cuatro pestañas
 * cruzada a lo ancho de una pantalla de 1280.
 */
@media (min-width: 481px) {
  .pia-nav { display: none; }
}