firefox: la bandera de firma en LAS TRES fases, y un guardián que lo comprueba en el artefacto

El build anterior selló con `MOZ_REQUIRE_SIGNING: true` DENTRO del omni.ja, pese a que el configure
aceptó la variable sin una queja. Cincuenta minutos para descubrirlo, y no al construir sino al
intentar instalar la extensión de la página de inicio — a dos recetas de distancia y con un error
(`ERROR_SIGNEDSTATE_REQUIRED`) que no nombra la bandera por ningún lado.

LA CAUSA ES LA QUE ESTA MISMA RECETA YA DOCUMENTABA PARA OTRA VARIABLE: las fases son shells
distintos y `mach build` re-ejecuta el configure cuando lo cree necesario. Por eso `RUST_TARGET` se
repite en las tres desde siempre; `MOZ_REQUIRE_SIGNING` estaba sólo en `configure`.

Y como el fallo es de los que viajan lejos y callados, la fase install ahora lo COMPRUEBA donde de
verdad importa —el `AppConstants.sys.mjs` que va dentro de omni.ja— y falla el build si no quedó en
`false`, con el mensaje que dice qué revisar. Un flag que el configure acepta y el artefacto ignora
es justo la clase de cosa que sólo se ve si alguien la mide.

Lo que se leyó para llegar acá, y no se dedujo: el parser de mozbuild confirma que el valor VACÍO
desactiva (`if values == ("",): return NegativeOptionValue()`) y que un env vacío sí se considera
presente (`if env is not None`). O sea que el mecanismo era correcto; lo que faltaba era que la
variable estuviera donde el build la vuelve a leer.

recipes/firefox.toml

@@ -269,6 +269,12 @@ echo "ThinLTO con --thinlto-jobs=$jl (MemTotal ${gib} GiB, nproc $n)"
 # a `nproc`. Es un tope, no una garantía.
 compile = '''
 export RUST_TARGET=x86_64-alpine-linux-musl   # ver la nota en la fase configure
+# ⚠ `MOZ_REQUIRE_SIGNING` TAMBIÉN ACÁ, Y NO ES REDUNDANCIA. Las fases son shells distintos y
+# `mach build` re-ejecuta el configure cuando lo cree necesario: exportarla sólo en la fase
+# `configure` produjo un artefacto con `MOZ_REQUIRE_SIGNING: true` pese a que el configure la
+# aceptó — 50 minutos de build para descubrirlo al abrir el navegador. Es exactamente la razón por
+# la que `RUST_TARGET` se repite en las tres fases.
+export MOZ_REQUIRE_SIGNING=
 export MOZBUILD_STATE_PATH="$PWD/.mozbuild"
 export MACH_BUILD_PYTHON_NATIVE_PACKAGE_SOURCE=system
 export MOZ_NOSPAM=1
@@ -280,9 +286,30 @@ echo "mach build -j$j (MemTotal ${gib} GiB, nproc $n)"
 '''
 install = '''
 export RUST_TARGET=x86_64-alpine-linux-musl   # ver la nota en la fase configure
+export MOZ_REQUIRE_SIGNING=                   # ídem
 export MOZBUILD_STATE_PATH="$PWD/.mozbuild"
 export MACH_BUILD_PYTHON_NATIVE_PACKAGE_SOURCE=system
 DESTDIR=/out ./mach install
+
+# ── GUARDIÁN: QUE LA BANDERA HAYA LLEGADO AL ARTEFACTO, NO AL CONFIGURE ───────────────────────
+# `MOZ_REQUIRE_SIGNING` es una bandera que el configure acepta sin ruido y que aun así puede acabar
+# en `true` dentro del artefacto (pasó: la exportábamos sólo en `configure`). El síntoma aparece
+# lejísimos —al intentar instalar una extensión de la distro, en otra receta, tras 50 minutos de
+# build— y no menciona la bandera por ningún lado. Se comprueba donde de verdad importa: en el
+# `AppConstants` que va DENTRO de omni.ja.
+python3 - <<'PY'
+import sys, zipfile
+z = zipfile.ZipFile("/out/usr/lib/firefox/omni.ja")
+n = [x for x in z.namelist() if x.endswith("AppConstants.sys.mjs")]
+if not n:
+    sys.exit("guardián: no encontré AppConstants.sys.mjs en omni.ja")
+t = z.read(n[0]).decode("utf-8", "replace")
+if "MOZ_REQUIRE_SIGNING: false" not in t:
+    sys.exit("guardián: MOZ_REQUIRE_SIGNING NO quedó en false — la distro no podría "
+             "instalar ninguna extensión propia. Revisá que la variable se exporte en TODAS "
+             "las fases (son shells distintos y mach re-ejecuta configure).")
+print("guardián: MOZ_REQUIRE_SIGNING = false en el artefacto")
+PY
 '''
 
 [deps]