perfil PGO v2: 46 páginas y 6,5× más ejecuciones registradas

El corpus se amplió por una MEDICIÓN, no por corazonada. Con las 36 de Mozilla
la ganancia era -9,4% en DOM/maquetación y -1,0% en 3d-raytrace, y la razón es
que un benchmark JIT-bound es casi ciego al PGO: el bucle caliente lo ejecuta
código que el JIT emite en runtime, y el PGO optimiza el intérprete, el GC y el
propio JIT, no lo que el JIT produce. El corpus de Mozilla está dominado en
número de páginas por SunSpider, o sea que entrenaba justo donde menos rinde.

Con las 10 de scripts/pgo-corpus/ sumadas, el efecto se ve EN EL PROPIO PERFIL:

    ejecuciones registradas   5.885.254.799 -> 38.498.366.335   (6,5x)
    máximo por función          416.219.136 ->  1.552.416.768   (3,7x)

Funciones y bloques totales no cambian (501.521 / 3.734.991) porque son la
estructura estática del binario instrumentado, no lo que se ejecutó.

Blob nuevo publicado y verificado bajándolo del mirror por el mismo camino que
usa hammer: 17.525.708 bytes, sha256 95472411.

recipes/firefox-pgo-profile.toml

@@ -1,9 +1,19 @@
 # firefox-pgo-profile — el perfil de ejecución que optimiza a firefox. UNA MEDICIÓN CONGELADA.
 #
 # ══ QUÉ ES ═════════════════════════════════════════════════════════════════════════════════════
-# `merged.profdata`: 501.521 funciones, 3.734.991 bloques y 5.885.254.799 ejecuciones registradas,
-# recogidas corriendo el `firefox-instrumentado` sobre el corpus de entrenamiento de Mozilla
-# (`build/pgo`: las 4 páginas de maquetación de blueprint y los benchmarks JS de js-input/sunspider).
+# `merged.profdata`: 501.521 funciones, 3.734.991 bloques y **38.498.366.335 ejecuciones**
+# registradas sobre un corpus de **46 páginas**: las 36 de Mozilla (`build/pgo`) MÁS las 10 de
+# maquetación propias de `scripts/pgo-corpus/`.
+#
+# ⚠ EL CORPUS SE AMPLIÓ POR UNA MEDICIÓN, NO POR CORAZONADA. Con sólo las 36 de Mozilla la ganancia
+# medida fue **−9,4 %** en una página de DOM/maquetación y **−1,0 %** en `3d-raytrace`. La razón es
+# que un benchmark JIT-bound es casi CIEGO al PGO —el bucle caliente lo ejecuta código que el JIT
+# emite en runtime, y el PGO optimiza el intérprete, el GC y el propio JIT, no lo que el JIT
+# produce—, y el corpus de Mozilla está dominado en número de páginas por SunSpider. O sea que
+# entrenaba mucho justo donde el PGO menos rinde. Las 10 nuevas van al camino que sí es C++ de punta
+# a punta: flexbox, grid, tablas, texto en columnas, selectores, pintado, transforms, SVG, scroll
+# pegajoso y layout thrashing. Efecto medido en el propio perfil: las ejecuciones registradas pasan
+# de 5.885.254.799 a 38.498.366.335 (**6,5×**).
 # `firefox` lo consume con `--enable-profile-use=cross`.
 #
 # ══ POR QUÉ ES UNA FUENTE PINEADA Y NO UNA RECETA QUE LO GENERA ════════════════════════════════
@@ -32,12 +42,12 @@
 # aplican por nombre de función— pero vale menos: las funciones que ya no existen se ignoran y las
 # nuevas quedan sin datos. Regenerarlo es su propia unidad de trabajo, no un efecto secundario.
 name    = "firefox-pgo-profile"
-version = "2026.09.07"
+version = "2026.09.08"
 license = "MPL-2.0"
 
 [source]
-tarball = "https://no-hay-upstream.invalid/hammer/firefox-pgo-2026-09-07.tar.xz"
-sha256  = "92edb9c56c87c0b489e61ed722d97b7fe5d6dc37ce48ffa3f3cf7523cc4d2dbf"
+tarball = "https://no-hay-upstream.invalid/hammer/firefox-pgo-2026-09-08.tar.xz"
+sha256  = "95472411ba252e14c4d57de7193d53e4ba35fbccf4819ba95ceff1ca843e4a7a"
 # ⚠ `0` Y NO EL DEFAULT. hammer recorta UN componente al extraer, porque los releases GNU vienen
 # con un `proyecto-version/` de más. Este tarball es nuestro y lleva el fichero en la raíz, así que
 # con el default se recortaba lo único que hay y el install moría en `cp: cannot stat