Etapa B3: /store y /var/lib/hammer en particiones dedicadas (GPT)

scripts/disk-image.sh ahora arma una imagen GPT de 3 particiones ext4 en vez
de una sola: vda1=/ , vda2=/store (CAS inmutable), vda3=/var/lib/hammer (estado
mutable). Construcción sin root ni loopback: cp -al stagea el rootfs por
hardlinks (vacía store/ y var/lib/hammer/, instala el wrapper /sbin/init),
mke2fs -d puebla cada ext4 bajo unshare -r (root-owned), sfdisk escribe la GPT
y dd conv=sparse,notrunc empalma cada fs en su offset (imagen sparse, ~2G
reales). El wrapper /sbin/init monta vda2/vda3 y hace exec de arje-zero (el
kernel sólo monta vda1). drive-rebuild.py: root=/dev/vda1 en modo DISK.

Consecuencia resuelta: con /store en su propia partición el sellado cruza
filesystems y rename(2) da EXDEV. Store::seal cae a copia recursiva a un
staging dentro del store (preserva symlinks+modos) + rename store-interno
(atómico, mismo FS) + borrado del origen. Test copy_tree añadido.

Verificado in-VM (kernel hammer, KVM): vda{1,2,3} montados dedicados, 0
errores Cross-device, stage1' == stage1 ✓ REPRODUCIBLE. Cierra el ☐ de
SDD 11 §6 (particionado/montaje en la imagen destino).

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

docs/11-bootstrap.md

@@ -182,8 +182,13 @@ hammer bootstrap manifest             # imprime el bootstrap.json (log de transp
   como receta git pinned en un lote posterior. ✅
 - **Layout de la semilla:** ingesta pura en Stage 0 + resolución del toolchain al usarlo
   (`SeedSpec::toolchain_dir`, localiza `zig` en raíz o hijo versionado). ✅
-- **Particionado/montaje** de `/store` y `/var/lib/hammer` en la imagen destino: track posterior
-  del roadmap. ☐
+- **Particionado/montaje** de `/store` y `/var/lib/hammer` en la imagen destino: ✅ (Etapa B3).
+  `scripts/disk-image.sh` arma una imagen GPT con 3 particiones ext4 dedicadas —
+  `/dev/vda1`→`/`, `/dev/vda2`→`/store` (CAS inmutable), `/dev/vda3`→`/var/lib/hammer` (estado
+  mutable). El kernel monta vda1; un wrapper `/sbin/init` monta vda2/vda3 y hace `exec` del init
+  real (arje-zero). Consecuencia que hubo que resolver: con `/store` en su propia partición, el
+  sellado del store cruza filesystems y `rename(2)` da EXDEV ⇒ `Store::seal` cae a copia-a-staging
+  dentro del store + rename store-interno (atómico). Verificado in-VM: rebuild ✓ REPRODUCIBLE.
 - **Kernel:** importado pinned ahora; from-source después. ☐
 
 ## 7. Auto-alojamiento: el builder rootfs (camino a Stage 2 pleno)