sergio/takana

Dos cierres del mismo día, los dos medidos por la otra sesión del frente sobre la imagen:

· la #3 queda contestada: con perfil sano el navegador pinta a +195 s y pide
  `set_window_geometry(1332, 852)` —el tamaño que el `xulstore` recuerda— y acata el
  `configure(1280, 692)` del maximizado. Ninguna cifra es 1152×720, o sea que `browser-init.js` no
  calculó nada: es lo correcto en un perfil que ya recuerda. Y de paso sale el discriminador barato
  entre las dos ventanas: el navegador pide `min_size` 638×120 y el diálogo 117×37;
· y una corrección de MÉTODO a lo que este mismo documento recomendaba ayer: leer el perfil con
  `debugfs` sobre el raw es válido con la imagen apagada, NO para leer lo que dejó un kill. Con el
  journal sucio `debugfs` se planta, con `-c` lee el estado pre-journal y ahí `prefs.js` figura de
  0 bytes — indistinguible de «el navegador borró el perfil», que es más grave y falso.

También queda escrito que la corrida que pinta LIMPIA el contador de caídas (el mecanismo visto
desde el otro lado: explica el «se arregla sola» sin hipótesis) y que una corrida sana no ensucia
el `xulstore`.

diff --git a/docs/26-atuq-envoltorio-gecko.md b/docs/26-atuq-envoltorio-gecko.md
index 6589e7b2..1d9c94a5 100644
--- a/docs/26-atuq-envoltorio-gecko.md
+++ b/docs/26-atuq-envoltorio-gecko.md
@@ -2087,6 +2087,15 @@ partición sin montarla y sin root:
     debugfs -R "dump /root/.config/mozilla/firefox/<id>.default-default/prefs.js /tmp/prefs.js" \
       "/mnt/cosecha/takana-cosmic-qemu.img?offset=$((264192*512))"
 
+⚠ **Y esa lectura MIENTE si la VM se acaba de matar, con una forma peligrosa** (medido el 2026-09-15
+por la otra sesión del frente): el ext4 del guest queda con el journal sucio, `debugfs` se planta con
+«Block bitmap checksum does not match» y con `-c` abre pero lee el estado **PRE-journal** — ahí
+`prefs.js` figura de **0 bytes** con la fecha de la corrida anterior. Un `prefs.js` vacío leído así se
+ve idéntico a «el navegador borró el perfil», que es un diagnóstico mucho más grave y falso. La
+lectura buena es **desde adentro**, después de que el mount replaye el journal: para eso están los
+campos `recent_crashes_antes` / `_despues` del arnés. `debugfs` sirve para mirar el estado *previo*
+con la imagen apagada, no para leer lo que dejó un kill.
+
 ##### La sospecha del §6.10.duodecies era falsa: Gecko SÍ ve la pantalla, 1280×800
 
 Se midió agregándole `WidgetScreen:5` al `MOZ_LOG` —el módulo que registra qué monitores arma el
@@ -2193,10 +2202,21 @@ con el árbol de fuentes, pero con la mitigación ya puesta. Dos consecuencias:
    por lo tanto re-sella el artefacto (~340 M de store y todas las sondas a repetir);
 2. **rehacer la serie de la tasa con perfil sano**: hoy hay UNA corrida limpia (+123 s) y el resto
    está marcado. «Cuánto tarda en pintar» vuelve a estar sin medir, y ahora se puede medir bien;
-3. **y la pregunta vieja sigue abierta con otra forma**: cuando el navegador abre ventana de verdad,
-   ¿respeta el `sizemode=maximized` de 1332×852 que el `xulstore.json` de ese perfil recuerda? Para
-   eso está `--xulstore ANCHOxALTO`, que corre una segunda fase en el MISMO arranque (mismo
-   compositor, misma carga) en vez de comparar dos arranques distintos.
+3. ~~¿respeta el `sizemode=maximized` que el perfil recuerda?~~ **CONTESTADA el mismo día: sí.** Con
+   perfil sano el navegador pintó a +195 s y el protocolo trae las dos cifras, cada una en su papel:
+   `set_window_geometry(26, 23, 1332, 852)` —el tamaño normal que restaura del `xulstore`— y
+   `configure(1280, 692)` acatado, que es el área de trabajo por el maximizado. Ninguna es 1152×720
+   ⇒ `browser-init.js` no calculó nada, que es lo correcto en un perfil que ya recuerda.
+
+   **De ahí sale el discriminador barato entre las dos ventanas**, y vale para cualquier corrida
+   futura: el navegador pide `set_min_size(638, 120)` —después (690, 172)— y
+   `set_max_size(16332, 16332)`; el diálogo pide `set_min_size(117, 37)` y `set_max_size(348, 16332)`.
+   Con mirar el `min_size` se sabe cuál abrió, sin leer el título.
+
+   Dos cosas más de esa corrida: `recent_crashes_despues` salió **ausente** —la corrida que pinta
+   LIMPIA el contador, que es el mecanismo visto desde el otro lado y explica el «se arregla sola»
+   sin ninguna hipótesis— y el `xulstore` quedó igual: **una corrida sana no ensucia lo que el perfil
+   recuerda**.
 
 ### 6.11 Y ahora la pregunta que faltaba: ¿REPRODUCE? (2026-09-07)