CLI: hammer bootstrap stage0 + limpieza de staging y e2e

Cablea el Stage 0 del bootstrap a la CLI: subcomando `bootstrap stage0
--url --sha256 --version [--seed zig|musl-cross-make]` que abre el store,
arma el SeedSpec y llama a hammer_bootstrap::stage0, imprimiendo el b3 del
artefacto sellado.

- stage0 ahora limpia el staging `.bootstrap-tmp` pase lo que pase (extraído
  stage0_into): un sha256 erróneo ya no deja el tarball a medio descargar bajo
  el store. Test reforzado para afirmarlo.
- e2e de CLL `bootstrap_cli.rs`: tarball falso vía file:// → sella + imprime
  hash, idempotente, sha erróneo falla sin sellar. Sin red.

Docs SDD 11 §5 y roadmap marcan Stage 0 (lib+CLI) hecho; Stage 1/2 pendientes.
Workspace 219 verde.

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

docs/10-roadmap.md

@@ -179,10 +179,13 @@ pre-requisito de validación.
 
 Diseño completo en [SDD 11 — Bootstrap from-scratch](11-bootstrap.md). Resumen:
 
-- **Bootstrap from-scratch** en tres etapas ([SDD 11 §3](11-bootstrap.md)): Stage 0 (toolchain
-  semilla `zig`/`musl-cross-make` sellado por hash), Stage 1 (userland mínimo cross-compilado:
-  musl + busybox/toybox + init + `hammerd`), Stage 2 (rebuild nativo dentro del rootfs y diff
-  de hashes ⇒ auto-alojamiento bit-reproducible). ⏭️ **Primer paso del track.**
+- **Bootstrap from-scratch** en tres etapas ([SDD 11 §3](11-bootstrap.md)):
+  - **Stage 0** ✅ — crate `hammer-bootstrap` + `hammer bootstrap stage0`: ingiere el toolchain
+    semilla pinned (`SeedSpec`, hash por identidad), verifica sha256 antes de sellar,
+    idempotente. Cubierto por 4 unit + 1 e2e de CLI (offline, `file://`).
+  - **Stage 1** ☐ — userland mínimo cross-compilado (musl + busybox/toybox + `arje` + `hammerd`).
+  - **Stage 2** ☐ — rebuild nativo dentro del rootfs y diff de hashes ⇒ auto-alojamiento
+    bit-reproducible.
 - Reemplazar el init de Alpine por **tu init** (bus por pipes nativo) — habilita el `CRASHED`
   real que la Fase 5 dejó diferido. **Decisión: adoptar `arje`** (init from-scratch ya existente
   en el monorepo `tawasuyu`, con PID 1 + supervisión real) en lugar de escribir uno nuevo —

docs/11-bootstrap.md

@@ -112,19 +112,23 @@ No introduce mecanismo nuevo de build: encadena recetas y persiste el manifiesto
 
 ```rust
 // hammer-bootstrap
-pub fn stage0(seed: SeedSpec, store: &Store) -> Result<ArtifactHash>;        // toolchain semilla
-pub fn stage1(seed: &ArtifactHash, store: &Store) -> Result<RootfsHash>;     // userland mínimo
-pub fn stage2(stage1: &RootfsHash, store: &Store) -> Result<VerifyReport>;   // rebuild + diff
-pub fn all(seed: SeedSpec, store: &Store) -> Result<BootstrapManifest>;
+pub fn stage0(seed: &SeedSpec, store: &Store) -> Result<ArtifactHash>;       // ✅ toolchain semilla
+pub fn stage1(seed: &ArtifactHash, store: &Store) -> Result<RootfsHash>;     // ☐ userland mínimo
+pub fn stage2(stage1: &RootfsHash, store: &Store) -> Result<VerifyReport>;   // ☐ rebuild + diff
+pub fn all(seed: &SeedSpec, store: &Store) -> Result<BootstrapManifest>;     // ☐
 ```
 
-CLI:
+`SeedSpec { kind, version, url, sha256 }` es la identidad pinned de la semilla; `seed_hash()`
+deriva el `ArtifactHash` de `(kind, version, sha256)` — no del `url` ni del host, así que
+cualquier espejo del mismo tarball produce el mismo artefacto.
+
+CLI (implementado lo de Stage 0; el resto pendiente):
 
 ```
-hammer bootstrap stage0 [--seed zig|musl-cross-make]
-hammer bootstrap stage1 [--target x86_64-linux-musl]
-hammer bootstrap stage2 --verify
-hammer bootstrap --all                # las tres + reporte de reproducibilidad
+hammer bootstrap stage0 --url URL --sha256 HEX --version V [--seed zig|musl-cross-make]   # ✅
+hammer bootstrap stage1 [--target x86_64-linux-musl]                                       # ☐
+hammer bootstrap stage2 --verify                                                           # ☐
+hammer bootstrap --all                # las tres + reporte de reproducibilidad             # ☐
 ```
 
 ## 6. Decisiones abiertas (fijadas en [ADR 0008](adr/0008-bootstrap-stages.md))