firefox: pasa a compiler=gcc — zig-cc choca con una negativa de upstream

Tercer fallo de configure, y el que decide: «Firefox does not support linking
statically with libstdc++». No es un flag. flags.configure:79 compila un C++
mínimo, lo pasa por llvm-objdump --private-headers y EXIGE encontrar un
`NEEDED …libc++`; zig enlaza libc++ estática para musl, así que ese NEEDED no
existe nunca. Es una negativa de Mozilla, no una opción.

Cambiar a gcc derriba los tres muros que zig-cc levantó, de una vez:
 1. el sondeo del linker (gcc se anuncia como «GNU ld», que Firefox reconoce),
 2. «Cannot find ar» (hay un ar de verdad; se quitan los wrappers de zig),
 3. libstdc++ COMPARTIDA — el gcc del lab es 15.2.0 con libstdc++.so.6.

Es una excepción consciente y del mismo tipo que la que el repo ya mantiene para
el kernel y cmake (ADR 0011), a la que se llegó por eliminación y no por
comodidad: los tres intentos con zig-cc están documentados en la cabecera.

⚠ El precio queda escrito en la receta: el lab NO entra en hash_inputs, así que un
Firefox construido con el gcc del lab queda más expuesto a la deriva del rootfs
que uno con zig-cc — dos labs con gcc distinto pueden sellar bytes distintos sin
que el store lo note. Misma deuda que ya cargan el kernel y las otras recetas
compiler=gcc, y razón para no ampliar esa lista sin agotar antes el camino zig.

recipes/firefox.toml

@@ -48,17 +48,14 @@
 #   --disable-crashreporter       manda telemetría a Mozilla; además pide breakpad.
 #   --disable-updater             la distro actualiza por hammer, no por un updater propio.
 #   --disable-tests               no entran al artefacto.
-#   (SIN --enable-linker)         Alpine pone `--enable-linker=lld` y acá NO se puede, aunque zig
-#                                 use lld por dentro. `toolchain.configure` sondea el linker con
-#                                 `$CC -fuse-ld=lld -Wl,--version` y clasifica por la SALIDA: busca
-#                                 «mold», «GNU ld», «GNU gold» o «LLD». zig se identifica como
-#                                 **`zig ld 0.16.0`**, que no casa con ninguno ⇒ `kind = "unknown"`.
-#                                 Eso solo no rompe (el código acepta «unknown»), pero **pedir el
-#                                 linker por nombre vuelve FATAL cualquier fallo del sondeo**:
-#                                 `if linker: … if result is None: die("Could not use lld as
-#                                 linker")`. Sin el flag, Firefox prueba lld igual unas líneas más
-#                                 abajo y, si el sondeo falla, sigue a gold y al linker por defecto
-#                                 — que es justamente el lld que zig trae. Mismo linker, sin el die.
+#   (SIN --enable-linker)         Se deja que Firefox detecte solo. Con `zig-cc` esto era
+#                                 OBLIGATORIO —zig se anuncia como `zig ld 0.16.0` y el sondeo de
+#                                 `toolchain.configure` clasifica por esa cadena buscando
+#                                 «mold»/«GNU ld»/«GNU gold»/«LLD»— y **pedir el linker por nombre
+#                                 vuelve FATAL cualquier fallo del sondeo**. Con gcc el linker sí se
+#                                 anuncia como «GNU ld», así que el flag ya no haría daño; se deja
+#                                 fuera igual porque no aporta nada y una perilla menos es una
+#                                 diferencia menos entre esta receta y las de Waterfox y Zen.
 name    = "firefox"
 version = "154.0"
 license = "MPL-2.0"
@@ -86,7 +83,28 @@ patches = [
 ]
 
 [build]
-compiler = "zig-cc"
+# ══ `gcc` Y NO `zig-cc` — TRES MUROS DE UNA VEZ ════════════════════════════════════════════════
+# El resto del corpus va con zig-cc y esta receta es una EXCEPCIÓN consciente, del mismo tipo que la
+# que el repo ya mantiene para el kernel y cmake (ADR 0011). Se llegó acá por eliminación, no por
+# comodidad — con zig-cc el configure de Firefox murió tres veces seguidas:
+#
+#   1. «Could not use lld as linker» — zig se identifica como `zig ld 0.16.0` y el sondeo de Mozilla
+#      clasifica por esa cadena buscando «LLD»/«GNU ld»/«GNU gold».
+#   2. «Cannot find ar» — zig trae `ar` como SUBCOMANDO y `check_prog` busca un ejecutable.
+#   3. **«Firefox does not support linking statically with libstdc++»** — y éste no es un flag:
+#      `flags.configure:79` compila un C++ mínimo, lo pasa por `llvm-objdump --private-headers` y
+#      exige encontrar un `NEEDED …libc++`. zig enlaza libc++ ESTÁTICA para musl, así que ese NEEDED
+#      no existe nunca. No hay perilla que apagar; es una negativa de upstream.
+#
+# El gcc del lab (15.2.0, con `libstdc++` COMPARTIDA) satisface los tres: `NEEDED libstdc++.so.6`,
+# un `ar` de verdad y un linker que se anuncia como «GNU ld».
+#
+# ⚠ EL PRECIO, ESCRITO: **el lab NO entra en `hash_inputs`**, así que un Firefox construido con el
+# gcc del lab queda más expuesto a la deriva del rootfs que uno con zig-cc — dos labs con gcc
+# distinto pueden sellar bytes distintos sin que el store lo note. Es la misma deuda que ya cargan el
+# kernel y las otras recetas `compiler=gcc`, y la razón por la que conviene no ampliar esta lista sin
+# haber agotado antes el camino de zig.
+compiler = "gcc"
 target   = "x86_64-linux-musl"
 link     = "dynamic"
 flags    = []
@@ -106,18 +124,6 @@ strip_debug = true
 
 [build.phases]
 configure = '''
-# ── ar/nm/ranlib: zig los trae como SUBCOMANDOS, y Firefox busca BINARIOS ──────────────────────
-# `moz.configure` hace `check_prog("AR", …)` y muere con «Cannot find ar»: no existe un ejecutable
-# llamado `ar` en el sandbox, existe `zig ar`. Un `AR="zig ar"` con espacio tampoco sirve — se
-# ejecutaría como un binario único llamado «zig ar» (el mismo gotcha que documentan la receta de
-# ffmpeg y el de los crates `cc` en las recetas Rust). La salida es un wrapper de UN SOLO TOKEN por
-# herramienta, que es el patrón ya establecido en este corpus.
-ZW="$PWD/.zwrap"; mkdir -p "$ZW"
-for t in ar ranlib nm objcopy; do
-  printf '#!/bin/sh\nexec zig %s "$@"\n' "$t" > "$ZW/$t"
-  chmod +x "$ZW/$t"
-done
-export AR="$ZW/ar" RANLIB="$ZW/ranlib" NM="$ZW/nm" OBJCOPY="$ZW/objcopy"
 export MOZBUILD_STATE_PATH="$PWD/.mozbuild"
 export MACH_BUILD_PYTHON_NATIVE_PACKAGE_SOURCE=system
 export MOZ_NOSPAM=1
@@ -155,8 +161,6 @@ MOZ
 # del host (medido en el LXC: 186 GiB en vez de 16), así que en un contenedor esta cuenta se degrada
 # a `nproc`. Es un tope, no una garantía.
 compile = '''
-ZW="$PWD/.zwrap"
-export AR="$ZW/ar" RANLIB="$ZW/ranlib" NM="$ZW/nm" OBJCOPY="$ZW/objcopy"
 export MOZBUILD_STATE_PATH="$PWD/.mozbuild"
 export MACH_BUILD_PYTHON_NATIVE_PACKAGE_SOURCE=system
 export MOZ_NOSPAM=1