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.

scripts/provee.py

@@ -42,7 +42,7 @@ import yupana
 
 ROOT = yupana.ROOT
 STORE = os.environ.get("HAMMER_STORE", str(ROOT / "store"))
-HAMMER = str(ROOT / "target/release/hammer")
+HAMMER = str(ROOT / "target/release/takana")
 CACHE = ROOT / "work/provee-cache.json"