firefox NO reproduce bit a bit: el BuildID es la fecha del build — medido y anotado, no arreglado de paso

Al abrir `application.ini` para el branding de atuq apareció esto:

    BuildID=20260905035306

Es la fecha y hora del build. Dos construcciones de la MISMA receta, con el mismo ArtifactHash,
producen bytes distintos. Es justo el agujero que el invariante de reproducibilidad existe para
cerrar, y no se ve en `build-state.json` porque el hash es input-addressed y no se mueve por esto.

El arreglo es conocido y lo usa Alpine: exportar `MOZ_BUILD_DATE` con un valor determinista.

NO se aplica de paso, a propósito: vive en una FASE, así que re-hashea la receta y cuesta otro build
de cuatro horas más el re-sellado de atuq, que cuelga de ella. Es su propia unidad de trabajo y
queda como 4.c en el plan del SDD 26.

El comentario se comprobó que NO mueve el hash antes de commitearlo (b3:aa90192a antes y después):
un comentario fuera de las fases no entra en `hash_inputs`, así que el firefox sellado sigue válido.

Y el §2.ter del SDD queda con el estado real de atuq v0.2 y su evidencia.

docs/26-atuq-envoltorio-gecko.md

@@ -282,8 +282,16 @@ bytes. Editar un CSS del overlay mueve el `ArtifactHash`; renombrar el directori
 Un `.swm` **no** puede llevar una receta derivada, y los cuatro sitios que lo tocan fallan
 diciéndolo: el manifiesto es compartible y necesita un puntero resoluble desde fuera.
 
-**Hecho el 2026-09-05** (commit `aeebb19`): `recipes/atuq.toml` + `recipes/atuq/`, hash
-`b3:2d6e4dcf`. La capa son cuatro ficheros —autoconfig, `atuq.cfg`, `chrome/atuq.css`,
+**Hecho el 2026-09-05** (commits `aeebb19` y `6f6c32b`): `recipes/atuq.toml` + `recipes/atuq/`.
+La **v0.2** (`b3:7eff4ba4`) ya trae el branding: `application.ini` (Vendor/Name/RemotingName/
+CodeName, con el `ID` intacto para no salirse del ecosistema de complementos), `brand.ftl` dentro de
+`browser/omni.ja`, los binarios renombrados, iconos propios y `.desktop`. El re-empaque preserva
+orden, `STORED` y fechas del original, y se verificó contra el artefacto: **5306 entradas, mismo
+orden, y una sola con contenido distinto**. El `BuildID` se deriva del contenido del overlay —no de
+la fecha— porque es la clave con la que Gecko invalida su startup cache: sin eso, un cambio de
+chrome arranca con la interfaz vieja y *parece* que el overlay no agarró.
+
+La capa de configuración de la v0.1 son cuatro ficheros —autoconfig, `atuq.cfg`, `chrome/atuq.css`,
 `policies.json`— y el CSS se registra como `USER_SHEET` desde autoconfig porque `userChrome.css`
 vive en el perfil y exigiría que el usuario prenda una pref: atuq tiene que verse como atuq en el
 primer arranque. Falta construirlo: su dep `firefox` está en vuelo.
@@ -312,7 +320,8 @@ siguiente.
 | 3.a | PGO: perfil bajo sway headless, **sellado como artefacto propio** y consumido por hash | la otra mitad de la ganancia | 3 |
 | 3.b | `wasi-sdk` + `wasi-compiler-rt` ⇒ RLBox encendido | cierra el hueco de seguridad del §3.bis | 2 |
 | 4 | **`atuq`: receta derivada + overlay de chrome** ✅ v0.1 escrita | el andamio de todo lo demás | 3 |
-| 4.b | Branding (`application.ini`, nombre del binario) + re-empaque de `omni.ja` | el chrome de verdad | 4, y ver el artefacto real |
+| 4.b | Branding + re-empaque de `omni.ja` ✅ v0.2 `b3:7eff4ba4` | el chrome de verdad | — |
+| 4.c | **`MOZ_BUILD_DATE` determinista en `firefox`** — hoy el `BuildID` es la fecha del build ⇒ el artefacto **no reproduce bit a bit** | el invariante de reproducibilidad | otro build de 4 h + re-sellar atuq |
 | 5 | Host de native messaging (tawasuyu) | los verbos del §6 | 4 |
 | 6 | `sct` v1 (extensión + testigo) | el diferenciador que nadie tiene | 5 |
 | 7 | Descargas al CAS | 6.2, y alimenta 6.9 | 5 |

recipes/firefox.toml

@@ -133,6 +133,16 @@ flags    = []
 # Entra en `hash_inputs` A PROPÓSITO (cambia el contenido del artefacto), y usa `zig objcopy`, que
 # siempre está en el sandbox ⇒ no agrega una dep de build.
 strip_debug = true
+# ⚠ DEUDA MEDIDA EL 2026-09-05: ESTE ARTEFACTO NO REPRODUCE BIT A BIT ═══════════════════════════
+# `application.ini` del artefacto sellado trae `BuildID=20260905035306`: la FECHA Y HORA del build.
+# Dos construcciones de esta misma receta, con el mismo hash, producen bytes distintos — que es
+# exactamente el agujero que el invariante de reproducibilidad existe para cerrar, y no se ve en
+# `build-state.json` porque el ArtifactHash es input-addressed y no se mueve.
+# El arreglo es el que ya usa Alpine: exportar `MOZ_BUILD_DATE` con un valor determinista en las
+# fases (su APKBUILD lo deriva de `SOURCE_DATE_EPOCH`; acá el candidato natural es un valor fijo,
+# que al vivir en el texto de la fase entra en `hash_inputs` y queda declarado).
+# NO se aplica de paso: cambiar una fase re-hashea la receta y cuesta otro build de cuatro horas
+# más el re-sellado de `atuq`, que cuelga de ella. Es su propia unidad de trabajo.
 
 [build.phases]
 configure = '''