takana etapa 3b: las 49 invocaciones pasan a ./target/release/takana

Los llamadores EJECUTABLES: scripts/ (incluida toda la granja), los runbooks y
CLAUDE.md. Seguro porque la 3a ya garantiza que el worker emite los dos
binarios, y porque en farm-lab-sync.sh el cargo build remoto precede a la
invocación remota en el mismo script.

Verificado: sintaxis de los 49 (bash -n / py_compile — ojo que
why-differs-barrido.sh es Python con extensión .sh) y `takana hash` devuelve
hash real sobre el store.

NO se toca en esta etapa, a propósito:
- La variable de entorno HAMMER=. Es interfaz de los scripts entre sí y hay
  llamadores que la fijan; renombrarla va con la etapa 4.
- docs/evidencia/ y los HANDOFF: son REGISTRO de lo que se corrió ese día.
  Reescribir un comando dentro de una evidencia la falsifica.
- docs/state/: es generado, se regenera solo.
- Los ADR y los docs de diseño: texto, y `hammer` sigue funcionando. Van con
  la etapa 5, que es la de churn de texto.

docs/runbooks/armador-de-kernel.md

@@ -99,7 +99,7 @@ no resuelven. `plan` no escribe en `recipes/` por su cuenta: ese directorio es e
 ⚠ **Y al construirla, `hammer build` va SIEMPRE bajo el lock compartido:**
 
 ```sh
-flock work/.farm-build.lock ./target/release/hammer --store ./store build recipes/linux-derivada.toml
+flock work/.farm-build.lock ./target/release/takana --store ./store build recipes/linux-derivada.toml
 ```
 
 `hammer build` comparte `work/sources/<dep>-<sha>` entre todas las recetas. Dos builds simultáneos

docs/runbooks/cosmic-desktop.md

@@ -352,8 +352,8 @@ cerró hoy en GNOME.
 
 ```sh
 cd ~/hammer
-./target/release/hammer --store store hash recipes/incoming-cosmic/<pieza>.toml   # dry-run, ~2ms
-./target/release/hammer build recipes/incoming-cosmic/<pieza>.toml --store store
+./target/release/takana --store store hash recipes/incoming-cosmic/<pieza>.toml   # dry-run, ~2ms
+./target/release/takana build recipes/incoming-cosmic/<pieza>.toml --store store
 ```
 
 ## 🏔 EL ESCRITORIO ENTERO, DIBUJADO (2026-08-04)

docs/runbooks/stage1-vm-boot.md

@@ -26,7 +26,7 @@
 - **Herramientas host**: `qemu-system-x86_64`, un kernel x86_64 (`/boot/vmlinuz-*`), `cpio`, `gzip`.
 - **Espacio/tiempo**: construir `arje-zero` vendorea las deps del **monorepo tawasuyu entero** — es
   pesado y lento la primera vez (se cachea después).
-- **El binario `hammer`**: `cargo build --release -p hammer-cli` ⇒ `./target/release/hammer`.
+- **El binario `hammer`**: `cargo build --release -p hammer-cli` ⇒ `./target/release/takana`.
 
 > El store debe vivir en la raíz del repo (`./store`) para que `BuildConfig` resuelva
 > `.dev-fs/alpine` como hermano (`store/..` = repo root). El toolchain de Stage 1 **no** es el de
@@ -35,7 +35,7 @@
 ## 2. Stage 0 — ingerir la semilla (zig)
 
 ```sh
-export HAMMER=./target/release/hammer
+export HAMMER=./target/release/takana
 export STORE=./store
 
 "$HAMMER" --store "$STORE" bootstrap stage0 \