bootstrap: -mcpu=baseline en zig cc — reproducibilidad CPU-independiente (Stage 2)

El rebuild in-rootfs de Stage 2 cazó un no-determinismo real: stage1 reconstruido
en la VM divergía del host (of_tree host=b3:94a4f1… vs VM=b3:ab615b…), aun con el
seal hash idéntico (el seal es of_inputs: mismo key ≠ mismos bytes).

Diagnóstico (control en el host, sin VM): un rebuild de hammerd en el host es
byte-idéntico al cacheado, así que la receta es determinista host-a-host y el cache
no está stale. La divergencia es del entorno de build de la VM: `zig cc` default a
`-mcpu=native` y hornea la ISA del builder en el C/asm de los build-scripts (blake3,
curve25519-dalek). El host tiene SHA-NI+AVX2; `-cpu Broadwell` (VM bajo TCG) no tiene
SHA-NI ⇒ codegen distinto ⇒ bytes distintos ⇒ of_tree distinto. Misma raíz que el
SIGILL de AVX del runbook §7 (binarios al CPU del builder, no a un baseline genérico).

Fix: `-mcpu=baseline` en TODOS los sitios zig cc — CC/CXX del sandbox, los dos
wrappers Cargo (.hammer-zig-cc) y CC/HOSTCC de la receta de busybox. Las rutas SIMD
del runtime (blake3/sha2) son asm con dispatch en runtime: siguen presentes. Bonus:
cierra el AVX/SIGILL del §7 (corre en qemu64 sin -cpu Broadwell).

Validado en el host: con baseline hammerd cambia de bytes (1672448 vs 1677584 —
confirma que el default no era baseline) y los 3 componentes rebuildan limpio
(stage1 rc=0). Nueva referencia CPU-independiente of_tree(stage1-baseline)=
b3:4408e44e2ec51c3769deffcd64dd1f6c2010d414418937c3fa7930a0ded3f845. Runbook §8c
documenta el cruce del muro Rust-offline (cargo vendor por la NIC, hammerd sellado
in-VM en 74m35s) y este diagnóstico+fix.

Nota (plan C.2): el flag de CPU no entra en of_inputs ⇒ cambio de toolchain/flags da
cache-hit con bytes viejos; cerrar ese "pin de toolchain al hash" es trabajo aparte.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

docs/runbooks/stage1-vm-boot.md

@@ -367,6 +367,49 @@ Sumado al coste de los builds Rust bajo TCG (horas, RAM justa ⇒ riesgo de OOM
 veredicto pleno **4/4** se completa en un host con **KVM + más RAM** (y, idealmente, un builder
 booteado desde **disco** en vez de initramfs puro, que además evita la fricción ramfs/ownership).
 
+### Rust-offline cruzado + un no-determinismo cazado: el CPU del builder (2026-06-11)
+
+**El muro Rust-offline cayó.** Se dio red a la VM (NIC e1000 qemu user-mode + `insmod e1000.ko` +
+config estática de `eth0` 10.0.2.15 + DNS de slirp + CA bundle de Alpine copiado a la ruta estándar,
+commits `09034a5`/`fd20e38`). Con eso `cargo vendor` resolvió **crates.io entero** (DNS+TLS), y
+**`hammerd` se compiló, instaló y selló dentro de la VM** (74 m 35 s bajo TCG). Para no pagar el
+vendoring del monorepo de arje-zero bajo TCG, esta corrida **preseed-eó** musl/busybox/arje-zero en
+el store del builder y dejó **sólo hammerd** para reconstruir in-VM (driver `work/drive-rebuild.py`).
+
+**Veredicto: `✗ DIVERGENTE`** — y es justo lo que Stage 2 existe para cazar.
+`of_tree(stage1)=b3:94a4f1…` (host) vs `of_tree(stage1')=b3:ab615b…` (VM). El **seal hash** del rootfs
+sí coincidió (`b3:f11ca6e5…`), pero el seal es `of_inputs` (recipe + `(name,hash)` de componentes):
+**mismo key ≠ mismos bytes**. Lo único reconstruido in-VM era `hammerd`, así que la divergencia está
+ahí.
+
+**Diagnóstico (experimento de control en el host, sin VM):**
+
+1. **Rebuild de `hammerd` en el host → byte-idéntico** al cacheado (`cmp` limpio, dos veces). La
+   receta es determinista host-a-host; el cache **no** está stale.
+2. ⇒ la divergencia es **del entorno de build de la VM**. La única entrada de codegen no fijada es el
+   **CPU del builder**: `zig cc` (que compila el C/asm de los build-scripts: blake3, curve25519-dalek)
+   **default a `-mcpu=native`** y hornea la ISA de quien compila.
+3. **Evidencia ISA:** el `hammerd` del host trae `sha256rnds2` (SHA-NI) ×32 y 3530 instrucciones
+   AVX2 (`ymm`). El host tiene `sha_ni`+`avx2`; **`-cpu Broadwell` (el de la VM bajo TCG) NO tiene
+   SHA-NI** ⇒ codegen distinto ⇒ bytes distintos ⇒ `of_tree` distinto. Es la misma raíz que el SIGILL
+   de AVX del §7 (binarios al CPU del builder, no a un baseline).
+
+**Fix — `-mcpu=baseline` en TODOS los sitios `zig cc`** (codegen al baseline x86-64 genérico,
+independiente del CPU): el `CC`/`CXX` del sandbox (`sandbox.rs`), los dos wrappers Cargo
+(`.hammer-zig-cc`, `lib.rs`) y los `CC`/`HOSTCC` de la receta de busybox. Las rutas SIMD que el
+runtime sí usa (blake3/sha2) son asm con dispatch en runtime: siguen presentes y funcionando. Bonus:
+cierra de paso el AVX/SIGILL del §7 (el binario corre en qemu64 sin `-cpu Broadwell`).
+
+**Validado en el host:** con baseline, `hammerd` cambia de bytes (1 672 448 vs 1 677 584 — confirma
+que el default NO era baseline) y **los 3 componentes rebuildan limpio** (`stage1 rc=0`). Nueva
+referencia **CPU-independiente**: `of_tree(stage1-baseline)=b3:4408e44e2ec51c3769deffcd64dd1f6c2010d414418937c3fa7930a0ded3f845`
+(con musl `57b66a2e`+busybox `56664d70`+arje `bd0f8475`+hammerd `d08fd273`, todos baseline salvo arje
+que quedó preseed nativo). **Próxima iteración:** re-correr el builder con el toolchain baseline y
+verificar que el rebuild in-VM de `hammerd` reproduce `4408e44e…` (✓); para el **4/4** pleno,
+rebuild baseline también de arje-zero. Nota de fondo (plan C.2): el flag de CPU **no** entra hoy en
+`of_inputs`, así que un cambio de toolchain/flags da cache-hit con bytes viejos — la misma tensión
+"pin de toolchain al hash" que conviene cerrar para que Stage 2 no dependa de borrar el store a mano.
+
 ## 9. Cross-check opcional — `arje-packager`
 
 arje trae su propio empaquetador (`03_ukupacha/arje/init/arje-packager`):