/* PIA — EL CHAT EN UN TELÉFONO: una pantalla, una tarea.
 *
 * Nodo 3c1a9f62, 18-ago-2026. Decidido por Zey esa noche, textual: «lo
 * profesional es que en mobile tenga lo que la industria ya acepta como mobile
 * layout, no un web aplastado».
 *
 * =============================================================================
 * POR QUÉ ESTE FICHERO NO ES UNA SECCIÓN MÁS DE pia-movil.css
 * =============================================================================
 *
 * pia-movil.css ADAPTA LA CAJA de las pantallas de ACCESO —#/welcome y
 * #/login—, y su cabecera declara una invariante que este fichero NO puede
 * cumplir: «quitar este <link> del index.html tiene que devolver el
 * comportamiento de escritorio intacto, cosa que sólo es verdad si está solo».
 * Lo de aquí no adapta una caja: CAMBIA QUIÉN OCUPA LA PANTALLA. Son dos
 * invariantes distintas, y meterlas en un fichero es cómo el siguiente lector
 * borra la mitad equivocada.
 *
 * Y sobre todo: aquélla arregla DESBORDES. Ésta arregla una ARQUITECTURA DE LA
 * INFORMACIÓN. Los desbordes se ven en una captura; esto no se ve en ninguna,
 * porque lo que falla cabe perfectamente.
 *
 * =============================================================================
 * EL DEFECTO, MEDIDO — no «se ve apretado»
 * =============================================================================
 *
 * Medido sobre la app VIVA con una sesión real (@root, 60 salas unidas), con
 * emulación de móvil por CDP: scripts/sonda-chat-movil.mjs.
 *
 * `.mx_MatrixChat > div` es un flex EN FILA con CUATRO hijos, y así se reparten
 * el ancho del teléfono:
 *
 *     ancho   espacios   LISTA   tirador   contenido
 *       320       69        0       13        238
 *       390       69        0       13        308
 *       430       69        0       13        348
 *       481       69        0       13        399
 *       760       69        0       13        678
 *       780       69      370        1        340
 *      1280       69      370        1        840
 *
 * LA LISTA DE SALAS MIDE CERO EN CUALQUIER TELÉFONO. No está ausente: está
 * MONTADA —12 filas en #/home, 33 con una sala abierta, 48px de alto cada una,
 * con su texto dentro— y con 0px de ancho. Un elemento de 0px y un elemento
 * ausente NO son lo mismo, y la diferencia es el diagnóstico entero: ausente
 * significa que falta una pantalla; 0px significa que la pantalla está ahí y no
 * se puede tocar.
 *
 * LO QUE VE EL PACIENTE: abre PIA en su móvil con 60 conversaciones y lee «Te
 * damos la bienvenida, root · Vamos a empezar» con tres botones para CREAR
 * conversaciones. Ninguna de las suyas. Y si consigue entrar en una sala por un
 * enlace, NO PUEDE SALIR: no hay ningún control de vuelta en la cabecera
 * (medido: cero botones con rótulo de atrás/volver/cerrar).
 *
 * LA CAUSA NO ES UNA MEDIA QUERY Y NO ES EL PUNTO DE CORTE DE M1. El vuelco
 * está en 780px = 69 + 370 + 1 + 340: es el componente de columnas
 * REDIMENSIONABLES de escritorio dándole a la lista lo que sobre después de un
 * mínimo de 340px para el contenido, y en un teléfono no sobra nada. El
 * redimensionador lo escribe EN LÍNEA:
 *
 *     panel de la lista   style="… flex: 0 1 0px …"     <- crecer 0
 *     panel de contenido  style="… flex: 100 1 0px …"   <- crecer 100
 *
 * Por eso ningún `overflow-wrap`, ningún `max-width` y ningún token de aire
 * tocan este fallo: no es un desborde, es un reparto.
 *
 * =============================================================================
 * ⚠️ POR QUÉ AQUÍ SÍ HAY `!important`, QUE EN ESTA CASA ESTÁ MAL VISTO
 * =============================================================================
 *
 * pia-movil.css explica que gana SIN `!important` porque el CSS de Element vive
 * dentro de `@layer app-web` y el CSS sin capa gana a cualquier CSS en capa.
 * Eso sigue siendo verdad y aquí también aplica — para todo lo que sea CSS.
 *
 * Pero LO QUE HAY QUE GANAR AQUÍ NO ES CSS: es un atributo `style` escrito por
 * JavaScript en cada render del redimensionador. 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 una declaración `!important` de autor,
 * porque la importancia se resuelve ANTES que la especificidad.
 *
 * O sea: `!important` aquí no es pereza ni un atajo de especificidad. Es la
 * ÚNICA herramienta con la que se puede escribir esta regla, y va sólo en las
 * tres propiedades que el redimensionador escribe en línea (`flex`, `display`,
 * `width`). Todo lo demás de este fichero va sin él, y si algún día se ve un
 * `!important` nuevo aquí sobre una propiedad que Element NO pone en línea,
 * está de más y hay que quitarlo.
 *
 * =============================================================================
 * EL PATRÓN QUE SE COPIA, Y DE DÓNDE SALE
 * =============================================================================
 *
 * No se inventa una navegación: se adopta la que ya usan las apps de referencia
 * y la propia app móvil de Element.
 *
 *   · Element X (la app móvil real de Element) NO tiene raíl vertical de
 *     espacios. La lista de chats es la pantalla raíz y los espacios son un
 *     FILTRO en horizontal arriba de esa lista. Element Web se ha traído de ahí
 *     los filtros —«Sin leer / Personas / Grupos / Menciones / Invitaciones»,
 *     que ya están en esta imagen— pero NO la desaparición del raíl.
 *   · WhatsApp y Telegram: lista a pantalla completa como raíz, conversación a
 *     pantalla completa como pantalla EMPUJADA, y una flecha de volver en la
 *     cabecera. Ninguna de las dos enseña lista y conversación a la vez en un
 *     teléfono, y ninguna gasta una columna fija en carpetas.
 *
 * LAS TRES DECISIONES, en el orden en que se aplican abajo:
 *
 *   C1 · UNA SOLA COLUMNA, Y LA RUTA DECIDE QUIÉN LA OCUPA.
 *        Sin sala abierta → la LISTA ocupa la pantalla.
 *        Con sala abierta → la SALA ocupa la pantalla.
 *        No hace falta escribir un router: Element YA pone la lista en un panel
 *        y la sala en el otro. Lo único que estaba roto era el reparto de ancho.
 *
 *   C2 · EL RAÍL DE ESPACIOS SE TUMBA, NO SE BORRA.
 *        69px fijos son el 17,7% de un teléfono de 390 y el 21,6% de uno de
 *        320. Borrarlo sin más perdería función: en PIA los espacios son las
 *        CARPETAS DE LOS PUENTES (Telegram, WhatsApp) y no hay ningún otro
 *        camino hasta ellas — los filtros de la lista no incluyen un filtro de
 *        espacio en esta versión (comprobado enumerando los chips: son cinco y
 *        ninguno es un espacio). Así que se tumba a una tira horizontal encima
 *        de la lista, que es donde Element X los pone.
 *
 *   C3 · LA SALA ES PANTALLA COMPLETA, CON VUELTA Y CON NOMBRE.
 *        Medido en la cabecera a 390px, de izquierda a derecha:
 *            avatar de sala ......... [100..140]
 *            NOMBRE DE LA SALA ...... [152..174]   22px
 *            videollamada ........... [238..270]   32px de alto
 *            hilos .................. [282..314]   32px de alto
 *            info de la sala ........ [326..358]   32px de alto
 *            caras de los miembros .. [376..420]   SE SALE (420 > 390)
 *        Al nombre de la sala —lo único que dice DÓNDE ESTÁS— le quedan 22px, y
 *        se lee «G..». Las caras se salen 30px. La tira de caras es una
 *        afinidad de escritorio: en un teléfono los miembros viven dentro de
 *        «info de la sala», que está ahí al lado. Se retira, y el nombre se
 *        queda con lo que ocupaba.
 *
 * LO QUE ESTE FICHERO NO HACE, A PROPÓSITO
 *   · NO sube a 44px los 46 controles del chat que están por debajo (§10 M5).
 *     Son un nodo aparte: este fichero cambia la NAVEGACIÓN, y mezclar un
 *     barrido de alturas con un cambio de arquitectura hace imposible saber
 *     cuál de los dos rompió qué. Se dejan contados en la sonda.
 *   · NO inyecta ningún control: el botón de volver no se puede escribir en CSS
 *     y vive en pia-lanzador.js, que ya tiene el patrón (colgar de <body>,
 *     fuera de React) y su motivo escrito.
 */

/* =============================================================================
 * C1 · UNA SOLA COLUMNA
 * =============================================================================
 *
 * El punto de corte es 480px y es EL MISMO de siempre (§10 M1: uno solo). No se
 * inventa uno nuevo aunque el fallo llegue hasta 779px: por encima de 480 hay
 * tabletas y ventanas de escritorio estrechas, donde dos columnas SÍ son lo
 * correcto y nadie ha medido PIA todavía. Un arreglo que se pasara de 480
 * cambiaría pantallas que no se han visto.
 */
@media (max-width: 480px) {

  /* 1.1 · La fila de cuatro columnas pasa a ser una rejilla de una.
   *
   * SE ELIGE `grid` Y NO `flex-direction: column` a propósito. Con una columna
   * de flex, los dos paneles se apilarían y habría que darle a uno alto 0;
   * con una rejilla, los dos paneles caen en LA MISMA CELDA (fila 2) y se
   * turnan con `display`, que es exactamente el modelo mental de «una pantalla
   * empuja a la otra». La fila 1 es para la tira de espacios, y vale `auto`,
   * así que cuando la tira se esconde (dentro de una sala) la fila desaparece
   * sola en vez de dejar un hueco.
   *
   * `minmax(0, 1fr)` y no `1fr`: una pista de rejilla tiene mínimo `auto`, o
   * sea el min-content de su contenido, y la línea de tiempo de una sala pide
   * mucho más que la pantalla. Sin el `minmax(0, …)` la fila 2 crecería por
   * debajo del teléfono y volveríamos a tener scroll. Es la misma mitad que se
   * olvida que §10 M6 nombra para flex (`min-width: 0`), en su forma de rejilla.
   *
   * EL `!important` DEL `display` ES OBLIGATORIO Y SE COMPROBÓ, no se puso por
   * si acaso. Este contenedor lleva EN LÍNEA:
   *     style="height:100%; width:100%; overflow:hidden; display:flex;
   *            flex-flow:row; touch-action:pan-y"
   * La primera versión de esta regla no lo llevaba: el navegador aceptó las dos
   * `grid-template-*` (se quedan como valores calculados) y descartó el
   * `display`, así que el contenedor SIGUIÓ SIENDO UN FLEX EN FILA y la regla
   * pareció puesta sin estarlo. La tabla de anchos de una regla que no se aplicó
   * y la de una regla que se aplicó y no sirve son IDÉNTICAS; por eso la sonda
   * informa ahora del `display` calculado del contenedor y no sólo del reparto.
   */
  .mx_MatrixChat > div {
    display: grid !important;
    grid-template-columns: 100%;
    grid-template-rows: auto minmax(0, 1fr);
  }

  /* 1.2 · El tirador de redimensionar no existe para un dedo.
   *
   * Son 13px —el 4,1% de un teléfono de 320— dedicados a arrastrar el borde
   * entre dos columnas que ya no hay. Y no es sólo espacio: `touch-action:
   * none` (lo trae en línea) apaga el gesto del navegador en esa franja, así
   * que además es una tira muerta al lado del contenido. */
  .mx_MatrixChat > div > .mx_Separator {
    display: none !important;
  }

  /* 1.3 · Los dos paneles, en la misma celda y a ancho completo.
   *
   * EL SELECTOR NO PUEDE IR POR CLASE Y HAY QUE DECIR POR QUÉ: los dos
   * envoltorios que se reparten el ancho NO TIENEN NINGUNA CLASE (los pinta el
   * componente de columnas redimensionables). Tampoco se apuntan por
   * `nth-child`, que se rompería en silencio si Element añadiera un panel. Se
   * apuntan por lo que LLEVAN DENTRO, con `:has()`, y por dos nombres que salen
   * del código fuente de Element y no de su compilador —`mx_LeftPanel_panel` y
   * sus dos hijos— así que no llevan hash y no caducan con la imagen.
   *
   * El `!important` de `flex` es lo explicado en la cabecera: gana al
   * `flex: 0 1 0px` que el redimensionador escribe EN LÍNEA. Sin él esta regla
   * no mueve un píxel y parecería puesta.
   */
  .mx_MatrixChat > div > div:has(> .mx_LeftPanel_panel) {
    grid-row: 2;
    grid-column: 1;
    flex: 1 1 auto !important;
    width: auto !important;
    min-width: 0;
  }

  /* 1.4 · Y la ruta decide cuál de los dos se ve.
   *
   * LA SEÑAL DE RUTA ES `body:has(.mx_RoomView)` Y ESTÁ MEDIDA, no supuesta:
   * `.mx_RoomView` NO EXISTE en el DOM en #/home y SÍ existe en #/room/…. O
   * sea que hay un selector puro para «hay una sala abierta» sin leer el hash,
   * sin JavaScript y sin que Element tenga que colaborar.
   *
   * `display: none` lleva `!important` por el mismo motivo que el `flex`: los
   * dos envoltorios traen `display: flex` en línea.
   */
  body:has(.mx_RoomView) .mx_MatrixChat > div > div:has(> .mx_LeftPanel_panel > .mx_LeftPanel_outerWrapper) {
    display: none !important;
  }
  body:not(:has(.mx_RoomView)) .mx_MatrixChat > div > div:has(> .mx_LeftPanel_panel > .mx_RoomView_wrapper) {
    display: none !important;
  }

  /* =========================================================================
   * C2 · EL RAÍL DE ESPACIOS SE TUMBA
   * ========================================================================= */

  /* 2.1 · De columna a tira, y sólo mientras se está en la lista.
   *
   * Dentro de una sala la tira se va entera: una conversación en un teléfono es
   * PANTALLA COMPLETA en las tres apps de referencia, y una tira de carpetas
   * encima de la conversación no lleva a ningún sitio que importe mientras
   * estás leyendo. La rejilla de 1.1 se queda en una sola fila sola. */
  .mx_MatrixChat > div > .mx_SpacePanel {
    grid-row: 1;
    grid-column: 1;
    flex-direction: row;
    align-items: center;
    /* UNA SOLA FILA — Y ESTO ERA EL PENDIENTE DEL BACKLOG 8df7d1b2, COBRADO.
     *
     * La versión anterior de esta regla llevaba `flex-wrap: wrap` y partía la
     * tira en DOS filas (~92px). No era un capricho de espaciado: en una sola
     * fila la tira cargaba SIETE controles —volver, avatar, los espacios,
     * hilos, ajustes rápidos y los dos lanzadores de PIA—, los seis fijos se
     * cobraban su ancho primero, y a los espacios les quedaba el resto: medido,
     * ~90px a 390 y ~30px a 320. O sea que la ÚNICA pieza específica de PIA
     * —las carpetas de los puentes, con sus contadores sin leer— era la que se
     * quedaba sin sitio. Bajarla a su propia línea era lo correcto ENTONCES.
     *
     * Y aquel comentario dejó escrita la salida buena, textualmente: «es que
     * home.html se quede con el tablero y los ajustes de PIA, que son suyos, y
     * entonces estas dos filas vuelven a ser una».
     *
     * Eso es exactamente lo que acaba de pasar, aunque por una puerta distinta
     * de la que se esperaba. Los tres accesos de PIA que le robaban el ancho a
     * la tira —la casa de volver al inicio y los dos lanzadores— ya no están en
     * ella: son tres de las cuatro pestañas de la barra de secciones de abajo
     * (nodo f85ada10), y quien los esconde es pia-nav-movil.css §N6. De siete
     * controles la fila baja a CUATRO —avatar, espacios, hilos, ajustes
     * rápidos— y vuelve a caber en una línea.
     *
     * NO SE ESCRIBE `flex-wrap: nowrap` PARA FORZARLO. `nowrap` sin `min-width:
     * 0` en los hijos no encoge: desborda en silencio, sin scroll y sin recorte
     * visible (§10 M6). El valor inicial de `flex-wrap` ya es `nowrap`, así que
     * quitar la declaración deja el comportamiento correcto sin añadir la
     * trampa; y el `min-width: 0` que hace que el `ul` scrollee en vez de
     * empujar sigue puesto, un piso más abajo, en 2.2. */
    width: auto;
    padding-left: var(--pia-margen-lienzo);
    padding-right: var(--pia-margen-lienzo);
    gap: var(--pia-esp-2, 8px);
    overflow: visible;
  }

  /* AQUÍ VIVÍAN DOS REGLAS QUE YA NO HACEN FALTA, y se dice para que nadie las
   * eche de menos ni las vuelva a poner:
   *
   *   · `ul { order: 9; flex-basis: 100% }` mandaba la lista de espacios a su
   *     propia línea. Sin `flex-wrap` no hay segunda línea a la que mandarla, y
   *     el `order` sólo conseguiría sacar los espacios de su sitio en el DOM
   *     sin motivo: en una fila, el orden de lectura y el del DOM ya coinciden.
   *
   *   · `.mx_QuickSettingsButton { margin-right: 88px }` le abría hueco a los
   *     dos lanzadores de PIA, que iban fijos sobre esa esquina. Los lanzadores
   *     se fueron a la barra de abajo, así que ese hueco era 88px de nada
   *     empujando a los espacios contra el borde izquierdo. */
  body:has(.mx_RoomView) .mx_MatrixChat > div > .mx_SpacePanel {
    display: none;
  }

  /* 2.2 · Y lo de dentro también se tumba — pero SÓLO la lista scrollea.
   *
   * La lista de espacios es un `ul` en columna que scrollea en vertical; en una
   * tira tiene que ser una fila que scrollea en horizontal.
   *
   * EL SCROLL VA EN EL `ul` Y NO EN LA TIRA, y ésa es la decisión que importa.
   * Si scrollea la tira entera, los iconos del final —hilos y ajustes— se van
   * de pantalla en cuanto haya cuatro espacios, y un control que se esconde al
   * desplazar una lista deja de ser un control fijo: el usuario no sabe que
   * existe. Con el scroll en el `ul`, lo que se desplaza son las carpetas y los
   * accesos se quedan quietos, que es lo que hacen las tres apps de referencia.
   *
   * `min-width: 0` es obligatorio y es la mitad que se olvida (§10 M6): sin
   * ella un ítem flex no encoge por debajo de su min-content —que aquí es la
   * suma de TODOS los espacios— y en vez de scrollear empuja a hilos y ajustes
   * fuera de la pantalla. Es exactamente el fallo que este fichero arregla un
   * piso más arriba, repetido dos niveles más abajo.
   *
   * `flex-shrink: 0` en los `li` evita lo contrario: que ocho espacios se
   * aplasten a nada en lugar de desplazarse. */
  .mx_MatrixChat > div > .mx_SpacePanel > ul {
    min-width: 0;
    flex-direction: row;
    align-items: center;
    height: auto;
    width: auto;
    overflow-x: auto;
    overflow-y: hidden;
  }
  .mx_MatrixChat > div > .mx_SpacePanel > ul > li {
    flex: 0 0 auto;
  }

  /* 2.3bis · Y lo que NO es la lista, quieto y alineado.
   *
   * El avatar de usuario, el centro de hilos y los ajustes rápidos son hijos
   * directos de la tira, y en la columna original estaban apilados con alturas
   * y márgenes verticales propios. Tumbados, esos márgenes los descolocan: en
   * la primera medición el botón de hilos quedaba 40px más abajo que la rueda
   * de ajustes, en la misma fila. Se les quita el crecimiento y el margen
   * vertical y se alinean con la fila, no consigo mismos. */
  .mx_MatrixChat > div > .mx_SpacePanel > .mx_UserMenu,
  .mx_MatrixChat > div > .mx_SpacePanel > .mx_ThreadsActivityCentre_container,
  .mx_MatrixChat > div > .mx_SpacePanel > .mx_QuickSettingsButton {
    flex: 0 0 auto;
    /* Los tres traen margen VERTICAL propio de cuando eran una pila: el menú de
     * usuario `12px 0 16px`, los ajustes rápidos `12px 0`. En una columna eso
     * era la separación entre ellos; tumbados es un desplazamiento hacia
     * abajo, y como cada uno trae el suyo, cada uno cae a una altura distinta.
     * Medido en la primera tira: la burbuja de hilos quedaba 9px por debajo de
     * la rueda de ajustes, en la misma fila. */
    margin-top: 0;
    margin-bottom: 0;
    height: auto;
    /* `align-items: center` en la tira alinea las CAJAS; esto alinea lo de
     * dentro. El contenedor de hilos mide 50px de alto con un botón de 32
     * dentro, así que sin esto la caja queda centrada y el botón no. */
    align-self: center;
    display: flex;
    align-items: center;
  }

  /* 2.4 · AQUÍ ESTABA LA MUDANZA DE LOS DOS LANZADORES DE PIA. SE RETIRA ENTERA,
   * PORQUE LA PREMISA QUE LA SOSTENÍA DEJÓ DE SER VERDAD — nodo f85ada10.
   *
   * Decía, textualmente, por qué los lanzadores del tablero y de los ajustes NO
   * podían esconderse en el teléfono: «`ajustes.html` —qué IA usa PIA— no tiene
   * hoy ningún otro camino […] esconderlos en el teléfono dejaría una pantalla
   * sin puerta». Era cierto y era el motivo correcto para recolocarlos arriba a
   * la derecha en vez de borrarlos.
   *
   * Ya no lo es: la barra de secciones de abajo (pia-nav-movil.css) rotula
   * «Tablero» y «Ajustes» como dos de sus cuatro pestañas, así que las dos
   * pantallas tienen puerta —una mejor, porque lleva nombre— y los botones
   * flotantes pasan a ser la MISMA navegación pintada dos veces en dos
   * lenguajes. Quien los esconde ahora es §N6 de aquel fichero, y está allí a
   * propósito: la razón por la que se van es la barra, así que si algún día
   * alguien borra la barra, los botones tienen que volver solos.
   *
   * SE BORRA EN VEZ DE DEJARSE, y esa fue la parte que costó decidir. Dejarla
   * habría sido dos reglas peleándose por los mismos dos botones —una que los
   * coloca arriba a la derecha y otra que los esconde— y, peor, un comentario
   * largo afirmando que ajustes.html no tiene otro camino justo debajo del
   * fichero que le acaba de dar uno. Un comentario que miente cuesta más que la
   * regla muerta que lo acompaña.
   *
   * CON ELLA SE VA TAMBIÉN `body:has(.mx_RoomView) .pia-lanzador:not(.pia-volver)`.
   * Servía para que, dentro de una sala, se escondieran los dos lanzadores SIN
   * llevarse por delante los botones de vuelta —que llevan la clase
   * `pia-lanzador` para heredar color, foco y z-index, y una vez se escondieron
   * los cuatro, incluida la única salida de la sala—. Ahora los dos lanzadores
   * están escondidos en TODO el móvil, no sólo dentro de una sala, así que la
   * regla no tenía a quién esconder.
   *
   * ⚠️ Y QUEDA UNA DEPENDENCIA REAL, dicha en voz alta: si pia-nav-movil.css no
   * se cargara, nadie escondería los dos lanzadores y volverían a su escalera de
   * pia-simplificar.css (`left: 18px`, a 100 y 144px del fondo) — o sea flotando
   * sobre la conversación, que es el fallo que esta sección arreglaba. Por eso
   * el Dockerfile guarda la presencia de los DOS ficheros y no sólo la de éste. */

  /* 2.3 · El plegado del raíl no significa nada sin raíl.
   *
   * `mx_SpacePanel_toggleCollapse` sirve para pasar de iconos a iconos+nombre
   * en una COLUMNA. En una tira no tiene estado que cambiar, y encima es de
   * 18px de alto: un control que no hace nada y además no se puede acertar. */
  .mx_SpacePanel_toggleCollapse {
    display: none;
  }
}

/* =============================================================================
 * C3 · LA SALA, A PANTALLA COMPLETA
 * =============================================================================
 *
 * Ver la tabla de la cabecera: al nombre de la sala le quedan 22px de 308 y la
 * tira de caras se sale 30px de la pantalla. Las dos cosas tienen la misma
 * causa —una cabecera de escritorio en un teléfono— y se arreglan quitando lo
 * que es de escritorio, no encogiendo lo que se sale.
 *
 * ⚠️ SE ACOTA A `.mx_RoomHeader` Y NO SE ESCRIBE GLOBAL sobre la clase del
 * componente. `mx_FacePile` se usa también en otros sitios de Element (lista de
 * espacios, vistas previas de sala) y ahí nadie lo ha medido. El criterio de
 * §10ter aplica igual aquí: el selector sólo puede llegar hasta donde se ha
 * medido.
 */
@media (max-width: 480px) {

  /* 3.1 · Las caras se van. Es lo que se sale, y es lo que le quita el sitio al
   * nombre. Los miembros siguen a un toque, dentro de «Info. de la sala», que
   * es el botón de al lado. */
  .mx_RoomHeader .mx_FacePile {
    display: none;
  }

  /* 3.2 · Y el nombre se queda con lo que quede, en una línea.
   *
   * `min-width: 0` es la mitad que se olvida de §10 M6 y aquí SÍ hace falta:
   * este envoltorio es un ítem flex con hermanos (los botones de acción) y sin
   * ella reclama el ancho de su texto entero y empuja a los botones fuera de la
   * cabecera. No se le pone `overflow-wrap: anywhere` porque el nombre de una
   * sala NO debe partirse a mitad de palabra: Element ya lo trunca con
   * `mx_RoomHeader_truncated`, y truncar es lo correcto para un rótulo de una
   * línea. M6 habla de datos que hay que poder LEER ENTEROS (un dominio, un
   * código); un nombre de sala se completa entrando. */
  .mx_RoomHeader .mx_RoomHeader_infoWrapper {
    min-width: 0;
    flex: 1 1 auto;
  }

  /* 3.3 · Y hueco a la izquierda para el botón de volver.
   *
   * El botón lo inyecta pia-lanzador.js colgado de <body> —fuera de React, por
   * el motivo que ese fichero ya tiene escrito— así que NO está en el flujo de
   * la cabecera y no empuja nada: hay que abrirle el hueco aquí, o se pintaría
   * encima del avatar de la sala. El número es el ancho del control (44px, §10
   * M5) y no un valor de gusto; se nombra en una variable para que el fichero
   * que lo pinta y el que le hace sitio no puedan derivar cada uno por su lado
   * — que es exactamente lo que le pasó al aire de tarjeta en §10bis. */
  .mx_RoomHeader {
    padding-left: var(--pia-ancho-volver);
  }

  /* 3.4 · Y EL CANALÓN DE 52px QUE SE COMÍA EL NOMBRE — nodo 898d6745
   *
   * 3.1 y 3.2 le devolvieron al nombre el ancho que le robaban las caras y los
   * botones. No bastó, y durante un tiempo nadie supo por qué: a 320px una sala
   * llamada «WhatsApp» seguía enseñando «W». Una sola letra.
   *
   * LO QUE PARECÍA: que la cabecera seguía sin repartir bien y había que
   * apretar algo más. LO QUE ERA, medido con los estilos COMPUTADOS y no
   * leyendo el CSS:
   *
   *     ancho 390 →  infoWrapper 138 · info 138 · rótulo  86   «WhatsApp»
   *     ancho 320 →  infoWrapper  68 · info  69 · rótulo  17   «W»
   *
   * El rótulo mide EXACTAMENTE 52px menos que su contenedor en los dos anchos
   * (138−86 = 52, 69−17 = 52). Un hijo que siempre mide N menos que su padre no
   * es un flex que encoge de más: es que hay N píxeles ocupados por otra cosa.
   * Y la otra cosa está en el CSS de Element, en una declaración suelta:
   *
   *     .mx_RoomHeader_info { padding-right: var(--cpd-space-13x) }   // 13x4 = 52
   *
   * Es un CANALÓN DE ESCRITORIO: separa el nombre de los botones de acción para
   * que un nombre largo no llegue a tocarlos. A 390 sobra sitio y no se nota. A
   * 320 quedan 69px para el nombre y el canalón se lleva 52 de esos 69 — el 75%
   * del sitio del rótulo gastado en aire, mientras el rótulo se recorta a una
   * letra. El canalón no es proporcional a nada: son 52px fijos, así que cuanto
   * más estrecha la pantalla, mayor es la parte que se lleva.
   *
   * SE VA EN MÓVIL, Y NO HACE FALTA SUSTITUIRLO POR NADA. Lo que el canalón
   * evita —que el nombre toque los botones— ya lo evita la propia fila: medido
   * a 320, la caja del nombre acaba en 164 y el primer botón empieza en 176.
   * Doce píxeles, que es la separación normal de esta barra. El canalón no
   * estaba separando: estaba reservando sitio DE MÁS y cobrándoselo al único
   * elemento de la cabecera que dice en qué conversación estás.
   *
   * RESULTADO, medido: el rótulo pasa de 17 a 68px a 320, y se lee «Whats…» en
   * vez de «W». Sigue truncado —en 68px no cabe «WhatsApp», y truncar es lo
   * correcto para un rótulo de una línea— pero truncado con suficiente texto
   * para reconocer la sala, que era el objetivo. A 390 y 430 NO CAMBIA NADA
   * VISIBLE: ahí el texto ya cabía (85px de 138), así que quitar el canalón sólo
   * ensancha una caja que ya le sobraba sitio.
   *
   * ⚠️ NO ES LO MISMO QUE EL `min-width: 0` DE 3.2 Y NO LO SUSTITUYE. Aquél
   * impide que el nombre EMPUJE a los botones fuera de la cabecera; éste impide
   * que el nombre se quede sin sitio dentro de su propia caja. Son dos fallos
   * opuestos y hacen falta los dos: si alguien borra 3.2 creyendo que esto lo
   * cubre, los botones se van de la pantalla. */
  .mx_RoomHeader .mx_RoomHeader_info {
    padding-right: 0;
  }
}

/* =============================================================================
 * C4 · LA VUELTA — el control que Element no tiene porque no lo necesita
 * =============================================================================
 *
 * En escritorio la lista está siempre al lado y no hay que «volver» a ningún
 * sitio. En cuanto C1 deja UNA sola columna, salir de una sala deja de ser
 * gratis: medido, la cabecera de sala tiene cero controles de vuelta. Sin esto,
 * C1 dejaría la app PEOR que antes — se entra en una conversación y no se sale.
 * Las dos mitades se cierran juntas o no se cierra ninguna.
 *
 * Los botones los crea pia-lanzador.js (un botón no se escribe en CSS) y viven
 * colgados de <body>, fuera de React, por el motivo que ese fichero ya tiene
 * escrito: un nodo metido dentro de un subárbol de React desaparece en el
 * siguiente render, de forma intermitente, que es la peor manera de fallar.
 *
 * ERAN DOS BOTONES EN EL MISMO SITIO QUE NUNCA SE VEÍAN A LA VEZ —la ‹ hacia la
 * lista y la casa hacia el inicio de PIA—, y desde el nodo f85ada10 EN EL
 * TELÉFONO SÓLO QUEDA LA ‹. La casa se convirtió en la pestaña «Inicio» de la
 * barra de secciones de abajo, que dice adónde lleva con una palabra en vez de
 * con un dibujo, así que aquí sobraba. pia-lanzador.js la sigue creando —la
 * necesita el escritorio tanto como antes, o sea nada, y no es de este nodo
 * tocar aquel fichero— y pia-nav-movil.css §N6 la esconde.
 *
 * Lo que NO cambia es de dónde sale la decisión: la ‹ se enciende con la MISMA
 * señal que C1 —`.mx_RoomView` en el DOM— para que la pantalla que se ve y el
 * destino del botón no puedan desincronizarse. Si algún día una de las dos
 * reglas cambia de criterio, la otra la sigue, porque es la misma condición
 * escrita una vez por cada lado y no dos criterios que hoy coinciden.
 *
 * Y ES AHORA MÁS IMPORTANTE QUE ANTES, no menos: dentro de una sala la barra de
 * secciones no existe (es el encargo de f85ada10), así que esta flecha vuelve a
 * ser LA ÚNICA salida de una conversación. Quien la toque, que lo sepa.
 */
@media (max-width: 480px) {
  /* Los 44px son el suelo de toque de §10 M5, y son EL MISMO número que reserva
   * la cabecera de la sala en 3.3. Se declara una vez, en `body`, y lo consumen
   * los dos sitios: es la lección de §10bis —una regla que describe un valor sin
   * nombrarlo se vuelve a teclear en cada sitio y deriva—, aplicada dentro de un
   * solo fichero.
   *
   * ERA TRES SITIOS Y AHORA SON DOS: la tira de espacios también le reservaba
   * estos 44px, a la casa de volver al inicio, y dejó de hacerlo cuando esa casa
   * se convirtió en la pestaña «Inicio» de la barra de secciones (nodo
   * f85ada10). Se dice aquí porque el valor de una constante compartida se lee
   * mal si la lista de quién la comparte se queda vieja. */
  body {
    --pia-ancho-volver: 44px;
  }

  .pia-volver {
    position: fixed;
    top: 10px;
    left: 0;
    width: var(--pia-ancho-volver);
    height: var(--pia-ancho-volver);
  }

  /* La ‹ sólo tiene sentido dentro de una sala: fuera, no hay nivel del que
   * volver. Ésta es la regla viva de las dos que había aquí.
   *
   * LA OTRA ERA `body:has(.mx_RoomView) #pia-volver-inicio { display: none }` Y
   * SE VA, porque `#pia-volver-inicio` ya no existe en el teléfono: la casa que
   * llevaba al inicio de PIA es ahora la pestaña «Inicio» de la barra de
   * secciones, y quien lo esconde es pia-nav-movil.css §N6, en TODO el móvil y
   * no sólo dentro de una sala. Una regla que esconde algo que ya está
   * escondido no es inofensiva: es una pista falsa para el siguiente que venga
   * a buscar quién manda sobre ese botón. */
  body:not(:has(.mx_RoomView)) #pia-volver-lista { display: none; }

  /* AQUÍ LA TIRA LE ABRÍA UN HUECO DE 44px A LA CASA DE VOLVER AL INICIO, con un
   * `margin-left` en el primer control de la fila. Se va con ella: reservarle
   * sitio a un botón que ya no se pinta son 28px de nada empujando el avatar
   * hacia dentro — el hueco de un control ausente, que es justo lo que hace que
   * una pantalla parezca mal alineada sin que se vea por qué.
   *
   * Y NO HAY QUE RESERVARLE NADA A LA ‹: dentro de una sala, que es la única
   * pantalla donde se pinta, esta tira no existe (regla de 2.1). Los dos
   * controles nunca coinciden en pantalla. `--pia-ancho-volver` se queda porque
   * lo sigue consumiendo la cabecera de la sala en 3.3, que es el otro sitio
   * donde la ‹ sí necesita que le abran paso. */
}

/* Y por encima de 480px NO EXISTEN. Es la invariante de este fichero al
 * completo: en escritorio la lista está siempre visible, no hay ningún nivel
 * del que volver, y un botón de vuelta ahí sería un control que no lleva a
 * ninguna parte. Va FUERA de la media query y en negativo, y no dentro de ella
 * en positivo, porque los botones los pinta un <script> que corre en TODOS los
 * anchos: si esta regla viviera dentro del `@media`, en escritorio no habría
 * ninguna regla escondiéndolos y saldrían los dos, uno encima del otro, sobre
 * la esquina de la lista de salas. */
@media (min-width: 481px) {
  .pia-volver { display: none; }
}

/* =============================================================================
 * C5 · EL SUELO DE TOQUE DEL CHAT — §10 M5, nodo 8df7d1b2, 18-ago-2026
 * =============================================================================
 *
 * Esto es el pendiente que la cabecera de este fichero dejó escrito («NO sube a
 * 44px los 46 controles del chat que están por debajo… son un nodo aparte»),
 * cobrado. Se hace ahora y no entonces por el motivo que decía aquella nota: un
 * barrido de alturas mezclado con un cambio de arquitectura hace imposible saber
 * cuál de los dos rompió qué.
 *
 * =============================================================================
 * LOS 20 CONTROLES, MEDIDOS Y REPARTIDOS EN CINCO ZONAS
 * =============================================================================
 *
 * scripts/sonda-toque-movil.mjs, a 390px con emulación de móvil por CDP, sesión
 * real de @root (63 salas). No son «46»: aquella cifra salía de una sonda que
 * publicaba `bajos: bajos.slice(0, 15)` sobre `nBajos: 20`, o sea que los cinco
 * últimos no se sabía cuáles eran. La sonda nueva no trunca.
 *
 *   nav.mx_RoomListPanel — la columna de la lista (13)
 *       «Opciones del grupo» …………… 28x28
 *       «+» (crear) ………………………………… 28x28
 *       «Desplegar los filtros» …… 28x28
 *       «Sin leer/Personas/Grupos/Menciones» … 30 de alto
 *       «Buscar ⌘K» ………………………………… 36x322
 *       «Explorar grupos» ………………… 36x36
 *       «Mensajes sin leer» ………… 36x176
 *   nav.mx_SpacePanel — la tira de espacios (3)
 *       «Menú de usuario» 36x42 · «Hilos» 32x32 · «Ajustes rápidos» 32x32
 *   header.mx_RoomHeader — la cabecera de la sala (4)
 *       videollamada, hilos e info ……… 32x32 cada uno
 *       el avatar de la sala …………………… 40x40
 *   div.mx_ToastContainer — los avisos apilados (2)
 *       «Omitir» 36x86 · «Activar» 36x92
 *   .mx_NewRoomIntro_buttons — la portada de una sala vacía (1)
 *       «Invitar solo a esta sala» 40x220
 *
 * SE MIRAN LAS DOS MEDIDAS Y NO SÓLO EL ALTO. M5 está escrito «44px de alto»
 * porque lo que se midió al escribirlo eran botones anchos de formulario, donde
 * el ancho nunca fue el problema. Ocho de estos veinte son ICONOS CUADRADOS: un
 * 28x28 cumpliría «44 de alto» con un min-height y seguiría siendo imposible de
 * acertar, porque un dedo no es una línea. La sonda cuenta los dos y dice cuál
 * falló.
 *
 * =============================================================================
 * LO QUE **NO** SUBE, Y POR QUÉ ESO NO ES DEJARLO A MEDIAS
 * =============================================================================
 *
 * La línea de tiempo de una sala tiene otros siete controles por debajo —la hora
 * del mensaje, el avatar y el nombre del remitente, los acuses de lectura, los
 * dos «expandir» del resumen de entradas y salidas—. NINGUNO sube, y no por
 * pereza: es §10ter aplicado literalmente. Todos comparten línea con el CUERPO
 * DEL MENSAJE o viven dentro de la prosa del resumen («Sala creada y configurada
 * por WhatsApp bridge bot. expandir»). Darles 44px hace que sus áreas se solapen
 * entre sí y con el mensaje, y el dedo deja de poder ELEGIR: son 44px que
 * empeoran la pantalla. Un suelo de toque que crea ambigüedad de toque no es un
 * arreglo.
 *
 * Y ESA DECISIÓN NO SE QUEDA EN ESTE COMENTARIO, que es donde se muere. Está
 * DECLARADA UNA A UNA, con su motivo, en la lista `EXENCIONES` de
 * sonda-toque-movil.mjs, y la sonda las IMPRIME en cada corrida junto al cero —
 * porque un cero solo se lee «no queda ninguno» y un cero al lado de sus siete
 * permisos se lee «no queda ninguno DE LOS QUE MIRO», que es lo que de verdad
 * pasa. La sonda avisa además de la exención que deje de encajar con nada: un
 * permiso escrito para algo que ya no existe eximirá lo que no debía el día que
 * Element reutilice esa clase.
 *
 * =============================================================================
 * LOS SELECTORES: POR DÓNDE VIVEN, Y LAS DOS EXCLUSIONES QUE HAY QUE ESCRIBIR
 * =============================================================================
 *
 * NINGUNO DE LOS 20 TIENE UNA CLASE A LA QUE APUNTAR. Element compila su CSS con
 * módulos y todos llevan hash: `_icon-button_1215g_8`, `_chat-filter_5qdp0_8`,
 * `_button_1nw83_8`. Apuntar ahí deja de aplicar EN SILENCIO en cuanto la imagen
 * de base se actualice — es el motivo por el que pia-movil.css §4 no apuntó a
 * `_button_<hash>` y fue por dónde vivían las cosas. Aquí igual: las cinco zonas
 * son `mx_*`, o sea nombres del FUENTE de Element y no de su compilador.
 *
 * Un suelo sobre «todos los botones de la zona» es más robusto que una lista de
 * controles: el que Element añada mañana nace cumpliendo. Pero eso obliga a
 * mirar QUÉ MÁS hay dentro de la zona, y en dos de las cinco hay algo que un
 * suelo rompería. Las dos salieron de volcar el DOM (`--volcar`), no de leer el
 * CSS, y ninguna se ve en una captura:
 *
 *   1 · UNA FILA DE LA LISTA ES UN <button> — `button.mx_RoomListItemView`, 48px,
 *       o sea que el suelo no la toca. Lo que sí la rompería es lo que lleva
 *       DENTRO: dos botones de 0px (el menú de la fila y «marcar como leída»)
 *       que sólo aparecen al pasar el ratón. Darles 44x44 los enciende en un
 *       teléfono —donde no hay ratón que los revele— y les quita 88px de ancho
 *       al nombre de la sala en las 16 filas. Un desastre invisible en el CSS y
 *       obvio en la pantalla. Por eso `:not(.mx_RoomListItemView *)`.
 *
 *   2 · UNO DE LOS CINCO FILTROS NO ES UN FILTRO: ES UN FANTASMA DE MEDIDA.
 *       `button.wrapping`, 0x0. Element pinta los cinco chips —«Sin leer,
 *       Personas, Grupos, Menciones, Invitaciones»— y deja el sobrante
 *       colapsado a cero para saber cuántos caben y cuándo enseñar la ‹∨› de
 *       «desplegar los filtros». Un suelo de 44x44 lo RESUCITA: pasa a ocupar,
 *       la cuenta de Element deja de cuadrar y la fila de filtros se parte en
 *       DOS, de 50px a 145. Y esto no lo caza ningún contador de dianas: la
 *       corrida en la que pasó dio CERO controles por debajo del suelo, verde
 *       entero, con la pantalla 95px más alta y un chip que no debía verse. Lo
 *       cazó mirar la captura. Por eso la sonda mide ahora también el ALTO DE
 *       LAS CINCO ZONAS: un suelo de toque sólo puede crecer las cajas que
 *       nombra, y si crece una fila entera es que ha tocado algo que no era.
 *
 *   3 · EL NOMBRE DE LA SALA TAMBIÉN ES UN <button> — `.mx_RoomHeader_infoWrapper`,
 *       63px. Ya cumple el suelo, así que el `min-height` le da igual; el que
 *       hace daño es el `min-width: 44px`, porque C3 (3.2) le pone `min-width: 0`
 *       A PROPÓSITO y ese cero es lo único que impide que reclame el ancho de su
 *       texto entero y empuje los botones fuera de la cabecera. Meter aquí un
 *       suelo de ancho sería volver a romper exactamente lo que C3 arregló, tres
 *       secciones más arriba y en el mismo fichero.
 *
 * =============================================================================
 * Y POR QUÉ EL SUELO NO ES SÓLO UN `min-height`
 * =============================================================================
 *
 * Ocho de estos controles son `display: block` con un icono de 20-24px dentro
 * (medido, no supuesto: la sonda publica el `display` computado de cada uno).
 * A un bloque, un `min-height` le crece la caja y le deja el icono pegado ARRIBA
 * Y A LA IZQUIERDA: la sonda mediría 44x44 y daría verde sobre un icono
 * descolocado. Un arreglo que el instrumento no puede distinguir de un fallo.
 * Por eso van también `display: flex` y los dos centrados.
 *
 * ¿Y no descoloca eso a los que YA eran flex — la barra de búsqueda de 322px, la
 * píldora «Mensajes sin leer», los cuatro filtros? No, y la razón es geométrica:
 * `justify-content` sólo mueve algo cuando SOBRA sitio en la caja. Esos tres
 * miden exactamente lo que mide su contenido (la búsqueda porque su rótulo lleva
 * `flex: 1` y empuja el ⌘K contra el borde), así que no sobra nada y el centrado
 * es un no-op. Se mueve justo lo que hay que mover: los iconos que acaban de
 * crecer.
 */
@media (max-width: 480px) {
  /* El suelo se nombra una vez y lo consumen las cinco zonas, en dos propiedades
   * cada una. Es la lección de §10bis —una regla que describe un valor sin darle
   * un nombre al que apuntar se vuelve a teclear en cada sitio y deriva—, que en
   * este mismo fichero ya obligó a declarar `--pia-ancho-volver` en C4.
   *
   * LOS DOS VALEN 44 Y NO SE ENCADENAN, a propósito. Escribir aquí
   * `--pia-ancho-volver: var(--pia-suelo-toque)` sería más bonito y dejaría a C4
   * dependiendo de que esta sección exista: el día que alguien la borre, la
   * variable se queda sin valor, el `padding-left` de la cabecera de la sala se
   * vuelve inválido y la ‹ se pinta encima del avatar — sin ningún error y en
   * una pantalla que nadie estaba mirando. Son el mismo número por el mismo
   * párrafo de §10 M5, y eso se dice en prosa, que es donde no rompe nada. */
  body {
    --pia-suelo-toque: 44px;
  }

  .mx_RoomListPanel button:not(.mx_RoomListItemView, .mx_RoomListItemView *, .wrapping),
  .mx_SpacePanel button,
  .mx_ToastContainer button,
  .mx_NewRoomIntro_buttons .mx_AccessibleButton {
    min-height: var(--pia-suelo-toque);
    min-width: var(--pia-suelo-toque);
    display: flex;
    align-items: center;
    justify-content: center;
  }

  /* --- LA CABECERA DE LA SALA VA APARTE, Y SÓLO SE LLEVA EL ALTO -------------
   *
   * Es la única fila del teléfono donde el suelo de ANCHO se cobra algo que
   * importa más que él, y no es una intuición: estaba escrito en el primer
   * intento de esta sección y lo cazó la sonda a 320px.
   *
   * Con `min-width: 44px` en los tres iconos y en el avatar, la cabecera pide
   *     44 (el hueco de la ‹, regla 3.3) + 44 (avatar) + 3x44 (iconos) = 220
   * y a 320px al NOMBRE DE LA SALA le quedan 28px. Medido, no estimado. O sea
   * exactamente el defecto que C3 existe para arreglar —«al nombre le quedan
   * 22px y se lee G..»— reintroducido por la sección que venía a mejorar la
   * pantalla. Un suelo de toque que deja al paciente sin saber en qué
   * conversación está no es una mejora de accesibilidad.
   *
   * ASÍ QUE AQUÍ EL SUELO ES DE ALTO Y LA HOLGURA LA PONE LA SEPARACIÓN, que es
   * como está escrito el criterio de verdad: WCAG 2.5.8 admite una diana menor
   * si la distancia de CENTRO A CENTRO con su vecina llega al umbral. Y llega,
   * con el número que este mismo fichero ya tenía medido en la tabla de C3:
   *     videollamada [238..270] · hilos [282..314] · info [326..358]
   * son 32px de icono y 12 de hueco, o sea 44 EXACTOS de centro a centro. Los
   * iconos quedan en 32x44 y el dedo sigue teniendo sus 44 en las dos
   * direcciones; lo que no se puede es cobrárselos dos veces, en la caja y en
   * el hueco, en la fila más estrecha de la app.
   *
   * ESTO NO ES «BAJAR EL LISTÓN PORQUE ME SALÍA ROJO», y por eso no se queda en
   * este comentario: la exención está declarada —sólo para el ANCHO, nunca para
   * el alto— en la lista `EXENCIONES` de sonda-toque-movil.mjs, con este mismo
   * motivo, y la sonda la imprime en cada corrida junto a su cero. Si alguien
   * cambia esta regla, el rojo vuelve solo.
   *
   * `min-width` sí se le sigue negando al NOMBRE, que además de no ser un icono
   * lleva el `min-width: 0` de C3 (3.2) — el que impide que reclame el ancho de
   * su texto entero y eche a los botones fuera de la cabecera. */
  .mx_RoomHeader button:not(.mx_RoomHeader_infoWrapper) {
    min-height: var(--pia-suelo-toque);
    display: flex;
    align-items: center;
    justify-content: center;
  }
}