sergio/takana

                    sin PGO   v1        v2        v3 (= v2 + jarlog)
  DOM/maquetación   23.008    20.851    20.527    20.502   (-10,9%)
  SunSpider         16.006    15.859    15.869    15.838   (-1,0%)
  jarlog solo:      -0,1% y -0,2%

Indistinguible de cero, y el argumento no es que los rangos se solapen —que se
solapan— sino que la MISMA variante varía ~1% entre corridas de días distintos
(v1 dio 20.851 hoy y 21.050 ayer). El suelo de ruido del banco es diez veces el
efecto buscado.

No es un fallo del jarlog: el banco corre con la caché de página CALIENTE, y ahí
reordenar omni.ja no ahorra ninguna lectura. Su terreno es el arranque en frío,
que este instrumento no reproduce.

Lo que SÍ está probado es que la función existe, y del lado del artefacto:
libxul IDÉNTICO byte a byte entre v2 y v3, omni.ja distinto en 26 bytes. El
jarlog tocó exactamente lo que debía y nada más. Se conserva porque es lo que
hace upstream y no cuesta nada; lo que no se afirma es una ganancia no medida.

Y no hizo falta la extensión Quitter, que este mismo documento daba por
bloqueante: profileserver.py sólo traduce JARLOG_FILE a MOZ_JAR_LOG_FILE.

Anotado además: los dos atípicos del banco son 120.034 y 120.030 ms, o sea
exactamente el timeout del arnés. No son ruido de carga sino corridas COLGADAS
al arrancar en headless, 2 de 56 (~3,5%).

diff --git a/docs/26-atuq-envoltorio-gecko.md b/docs/26-atuq-envoltorio-gecko.md
index 965af1c7..6b69e688 100644
--- a/docs/26-atuq-envoltorio-gecko.md
+++ b/docs/26-atuq-envoltorio-gecko.md
@@ -272,6 +272,33 @@ alcanza.
 transitorio. **La mediana lo ignora por diseño**; una media lo habría convertido en «v2 es
 catastróficamente peor». Fue la razón de elegir mediana antes de ver un solo número.
 
+**EL JARLOG: PUESTO, PROBADO EN EL ARTEFACTO, NO MEDIBLE EN EL BANCO (2026-09-08).** Desde
+`d9833a58` el perfil trae también el `jarlog` y `firefox` lo consume con `--with-pgo-jarlog`. No
+hizo falta la extensión `Quitter` de Mozilla, que este documento daba por bloqueante: su
+`profileserver.py` sólo traduce `JARLOG_FILE` a `MOZ_JAR_LOG_FILE` en el entorno del navegador.
+
+| | sin PGO | v1 (36 pág.) | v2 (46 pág.) | v3 (= v2 + jarlog) |
+|---|---|---|---|---|
+| DOM/maquetación | 23.008 ms | 20.851 (−9,4 %) | 20.527 (−10,8 %) | 20.502 (−10,9 %) |
+| SunSpider | 16.006 ms | 15.859 (−0,9 %) | 15.869 (−0,9 %) | 15.838 (−1,0 %) |
+
+**El jarlog solo aporta −0,1 % y −0,2 %: indistinguible de cero.** Y el argumento no es que los
+rangos se solapen —que se solapan— sino que **la misma variante varía ~1 % entre corridas de días
+distintos** (v1 dio 20.851 hoy y 21.050 ayer). El suelo de ruido del banco es **diez veces** el
+efecto buscado.
+
+Eso NO es un fallo del jarlog: es que el banco corre con la **caché de página caliente**, y ahí
+reordenar `omni.ja` no ahorra ninguna lectura. Su terreno es el arranque EN FRÍO, que este
+instrumento no reproduce; medirlo pediría vaciar la caché entre corridas, que es una acción de
+sistema. **Lo que sí está probado es que la función existe**, y del lado del artefacto: `libxul` es
+IDÉNTICO byte a byte entre v2 y v3 y el `omni.ja` difiere en 26 bytes — el jarlog tocó exactamente
+lo que debía tocar y nada más. Se conserva porque es lo que hace upstream y no cuesta nada; lo que
+no se afirma es una ganancia que no se midió.
+
+⚠ **Dato que los datos delatan:** los dos valores atípicos del banco son 120.034 y 120.030 ms, o sea
+exactamente el `timeout 120` del arnés. No son ruido de carga: son corridas COLGADAS al arrancar en
+headless, 2 de 56 (~3,5 %). Sin perseguir, pero anotado.
+
 ⚠ Y lo que este banco NO puede afirmar: las 10 páginas nuevas ejercitan los mismos subsistemas que
 la página de medición, así que el parentesco con lo que ahora se entrena es mayor que antes. El
 −11,4 % es real para ESTA carga; generalizarlo a «cualquier página» sería justo el error que el