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.

CLAUDE.md

@@ -7,13 +7,13 @@ trabajo de otro sin enterarse. El resto del diseño está en `docs/`.
 ## 1. Todo `hammer build` va envuelto en `flock`
 
 ```sh
-flock work/.farm-build.lock ./target/release/hammer --store ./store build <receta>
+flock work/.farm-build.lock ./target/release/takana --store ./store build <receta>
 ```
 
 Para una tanda, tomar el lock una sola vez y no por receta:
 
 ```sh
-flock work/.farm-build.lock bash -c 'for r in ...; do ./target/release/hammer --store ./store build "$r"; done'
+flock work/.farm-build.lock bash -c 'for r in ...; do ./target/release/takana --store ./store build "$r"; done'
 ```
 
 **Por qué.** `hammer build` comparte `work/sources/<dep>-<sha>` entre todas las recetas. Dos builds