takana etapa 5d: comentarios de crates, CLAUDE.md y el skill de granja

205 lineas en 73 ficheros de crates, mas la prosa de CLAUDE.md y del skill,
que se me habian quedado afuera de los barridos anteriores (no eran ni recetas
ni docs/ ni scripts/).

EL BARRIDO ANCHO ESTUVO A UN COMMIT DE ROMPER EL CORPUS ENTERO.

El primer intento reescribia los .rs completos, no solo los comentarios. Entre
las lineas de codigo que tocaba estaban SIETE etiquetas de separacion de
dominio, que son ENTRADA DE HASH:

  b"hammer-tree-v1"        <- el prefijo de ArtifactHash::of_tree (hash.rs:60)
  b"hammer-seed-v1"           la funcion que hashea TODOS los artefactos:
  b"hammer-stage1-rootfs-v2"  cambiarla mueve los 4750 hashes del store
  b"hammer-product-rootfs-v3"
  b"hammer-product-attested-v2"
  b"hammer-builder-rootfs-v1"
  b"hammer-attest-dev-rootkey-0001!!"  <- clave raiz de atestacion, [u8;32]

Revertido y rehecho solo sobre comentarios, esquivando ademas las cadenas
crudas de Rust (r#"..."#) porque el SYSTEM_PROMPT del traductor tiene lineas
que empiezan como comentario.

Controles: las 7 etiquetas siguen ahi, el diff toca CERO lineas de codigo,
605 tests en verde y el hash de zlib sigue en b3:dc363f26.

La leccion es la misma de toda esta etapa: un literal que parece prosa puede
ser entrada de hash, y la unica forma de saberlo es mirar donde se usa.

crates/takana-recover/src/main.rs

@@ -1,11 +1,11 @@
 //! `hammer-recover` — auto-recuperación de upgrades al **arranque** (E4 / refinamiento #4b).
 //!
-//! El producto NO lleva el CLI `hammer` completo; este mini-binario (estático musl) es lo único que el
+//! El producto NO lleva el CLI `takana` completo; este mini-binario (estático musl) es lo único que el
 //! sistema instalado necesita para auto-sanar un upgrade interrumpido. El wrapper `/sbin/init` lo corre
 //! **tras montar `/store` y `/var/lib/hammer`** y **antes** de incarnar arje-zero:
 //!
 //! - Sin intento pendiente ⇒ no-op (el caso normal).
-//! - Con un `pending.json` (un `hammer upgrade apply` cortado por un apagón/reinicio): intenta
+//! - Con un `pending.json` (un `takana upgrade apply` cortado por un apagón/reinicio): intenta
 //!   **completar** (roll-forward, re-ejecuta el plan idempotente + commitea); si no puede (p.ej. el árbol
 //!   ya no está en `/store`), **deshace** (roll-back) para dejar el FHS consistente. En cualquier caso el
 //!   sistema arranca en un estado coherente, no a medias.