SDD 26: el corpus ampliado rinde — de -9,6% a -11,4% en maquetación

sin PGO    v1 (36 pág)      v2 (46 pág)
  DOM/maquetación       23.285 ms  21.050 (-9,6%)   20.640 (-11,4%)
  SunSpider 3d-raytrace 16.003 ms  15.846 (-1,0%)   15.857 (-0,9%)

La mejora en maquetación NO se afirma por las medianas sino por la separación:
SEIS de las siete muestras de v1 son más lentas que TODAS las de v2; sólo una
cae dentro del rango de v2.

En SunSpider v1 y v2 son INDISTINGUIBLES —los valores se entrelazan por
completo—, que es exactamente lo esperable: ese camino lo ejecuta el JIT y el
PGO no lo toca. Un corpus mejor no puede mejorar lo que el PGO no alcanza. El
-0,9% frente al -1,0% no dice que v2 sea peor ahí: dice que no se distingue.

Una de las siete corridas de v2 dio 120.029 ms contra ~20.600 de las otras seis.
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 número.

Y lo que el banco no puede afirmar, escrito: 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 el mismo error que cometía el corpus de
Mozilla, en la otra dirección.

docs/26-atuq-envoltorio-gecko.md

@@ -251,9 +251,31 @@ lo que un usuario percibe: la medición cubre el ciclo COMPLETO del proceso (arr
 capturar → salir), no el rendimiento en régimen de una página ya cargada. De ahí que hasta la página
 de SunSpider tarde 16 s: casi todo es arranque.
 
-**Corolario para el corpus de entrenamiento:** está sesgado hacia JS (SunSpider domina en número de
-páginas) justo donde el PGO menos rinde. Un corpus con más maquetación y menos aritmética
-probablemente daría más ganancia. Es una unidad de trabajo propia y no se hace de paso.
+**Corolario para el corpus de entrenamiento — APLICADO Y MEDIDO (2026-09-08).** El corpus estaba
+sesgado hacia JS justo donde el PGO menos rinde, así que se le sumaron 10 páginas de maquetación
+propias (`scripts/pgo-corpus/`): flexbox, grid, tablas con los dos algoritmos de layout, texto en
+columnas, selectores contra 600 reglas, pintado, transforms, SVG, scroll pegajoso y layout
+thrashing. El perfil pasó de 5.885.254.799 ejecuciones registradas a **38.498.366.335 (6,5×)**.
+
+| | sin PGO | PGO v1 (36 pág.) | PGO v2 (46 pág.) |
+|---|---|---|---|
+| DOM/maquetación, fuera del corpus | 23.285 ms | 21.050 ms (−9,6 %) | **20.640 ms (−11,4 %)** |
+| SunSpider `3d-raytrace` | 16.003 ms | 15.846 ms (−1,0 %) | 15.857 ms (−0,9 %) |
+
+**La mejora en maquetación es real y no de medianas:** SEIS de las siete muestras de v1 son más
+lentas que TODAS las de v2; sólo una cae dentro del rango de v2. En SunSpider, en cambio, v1 y v2
+son **indistinguibles** —los valores se entrelazan por completo— que es justo lo esperable: ese
+camino lo ejecuta el JIT y el PGO no lo toca. Un corpus mejor no puede mejorar lo que el PGO no
+alcanza.
+
+⚠ Una de las siete corridas de v2 dio 120.029 ms contra ~20.600 de las otras seis: un atípico
+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.
+
+⚠ 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
+propio corpus de Mozilla cometía al revés.
 
 **Y la pregunta que un insumo no determinista obliga a hacer, respondida: `firefox` SIGUE
 REPRODUCIENDO bit a bit** (`verificar-repro.sh`: REPRODUCEN 1, DERIVA 0, NO-DETERMINISMO 0). Era el