jarlog: la mitad del PGO que faltaba — el orden de omni.ja para el arranque

El jarlog registra en qué orden se LEEN los ficheros dentro de omni.ja al
arrancar; con él, el empaquetador los reordena y el arranque hace lecturas
secuenciales en vez de saltar por el archivo.

NO hizo falta la extensión Quitter de Mozilla, que era lo que yo daba por
bloqueante: basta MOZ_JAR_LOG_FILE en el entorno del navegador. Su
profileserver.py sólo traduce JARLOG_FILE a esa variable — leerlo costó un grep
y ahorró rehacer el arnés entero.

Y se genera en una corrida APARTE, que está medido y no supuesto. Mozilla lo
emite en la misma sesión del profileserver; nuestro arnés arranca un navegador
POR PÁGINA, así que había que saber si el fichero se acumula o se pisa. Se pisa:
tras rejilla.html y tras tablas.html dio exactamente los mismos 27.652 bytes y
469 líneas. Su contenido lo domina el ARRANQUE, no la página, así que una
corrida dedicada vale igual que una de 46 — rehacer el perfilado sólo para
obtenerlo habría sido gasto sin diferencia. Se conserva el profdata ya medido
(el del -11,4%), que es lo que hace comparables los números.

Guardián propio: un jarlog vacío o que no nombre los archivos reales NO rompe el
build de firefox, sólo deja el omni.ja sin ordenar — o sea que se pierde justo
lo que se vino a buscar, en silencio. Se exige que mencione los DOS archivos que
el navegador abre (omni.ja y browser/omni.ja).

recipes/firefox-pgo-profile.toml

@@ -14,7 +14,16 @@
 # 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`.
+# Y desde 2026-09-08 también el **`jarlog`**: el orden en que se leen los ficheros dentro de
+# `omni.ja` al arrancar, para que el empaquetador los reordene y el arranque lea secuencialmente.
+# `firefox` los consume con `--enable-profile-use=cross` y `--with-pgo-jarlog`.
+#
+# ⚠ EL JARLOG SE GENERA EN UNA CORRIDA APARTE, Y ESO ESTÁ MEDIDO, NO SUPUESTO. Mozilla lo emite en
+# la misma sesión del `profileserver.py`; acá el arnés arranca un navegador POR PÁGINA, así que
+# había que saber si el fichero se acumula o se pisa. Se pisa: tras `rejilla.html` y tras
+# `tablas.html` dio **exactamente los mismos 27.652 bytes y 469 líneas**. O sea que su contenido lo
+# domina el ARRANQUE y no la página, y por eso una corrida dedicada vale igual que una de 46 —
+# rehacer el perfilado entero sólo para obtenerlo habría sido gasto sin diferencia.
 #
 # ══ POR QUÉ ES UNA FUENTE PINEADA Y NO UNA RECETA QUE LO GENERA ════════════════════════════════
 # **El perfil NO ES DETERMINISTA**: los contadores dependen del timing de la corrida, así que dos
@@ -42,12 +51,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.08"
+version = "2026.09.08b"
 license = "MPL-2.0"
 
 [source]
-tarball = "https://no-hay-upstream.invalid/hammer/firefox-pgo-2026-09-08.tar.xz"
-sha256  = "95472411ba252e14c4d57de7193d53e4ba35fbccf4819ba95ceff1ca843e4a7a"
+tarball = "https://no-hay-upstream.invalid/hammer/firefox-pgo-2026-09-08b.tar.xz"
+sha256  = "92497cddca82a3e92a6fbb80b8d78245543ed25418a11b681f4b28d890e3a1f0"
 # ⚠ `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
@@ -64,6 +73,7 @@ install = '''
 set -e
 mkdir -p /out/usr/share/firefox-pgo
 cp merged.profdata /out/usr/share/firefox-pgo/merged.profdata
+cp jarlog          /out/usr/share/firefox-pgo/jarlog
 
 P=/out/usr/share/firefox-pgo/merged.profdata
 
@@ -80,4 +90,18 @@ test "$n" -gt 100000 || {
   exit 1
 }
 echo "guardián: perfil válido — $n funciones, $(stat -c%s "$P") bytes"
+
+# ── GUARDIÁN DEL JARLOG ──────────────────────────────────────────────────────────────────────
+# El jarlog es el orden en que se LEEN los ficheros dentro de `omni.ja` al arrancar; con él, el
+# empaquetador los reordena para que el arranque haga lecturas secuenciales. Un jarlog vacío o que
+# no nombre los archivos reales no rompe el build de firefox — sólo deja el `omni.ja` sin ordenar,
+# o sea que se pierde justo lo que se vino a buscar, en silencio. Se exige que nombre los DOS
+# archivos que el navegador abre.
+J=/out/usr/share/firefox-pgo/jarlog
+test -s "$J" || { echo "!! el jarlog está vacío o no existe" >&2; exit 1; }
+for a in omni.ja browser/omni.ja; do
+  grep -q "^$a " "$J" || { echo "!! el jarlog no menciona '$a' — ¿se generó sin arrancar el navegador?" >&2
+    awk '{print $1}' "$J" | sort -u | head -5 >&2; exit 1; }
+done
+echo "guardián: jarlog con $(wc -l < "$J") entradas sobre omni.ja y browser/omni.ja"
 '''