takana etapa 5c: comentarios de scripts, MOTD, y un BUG que introdujo la etapa 4

250 líneas de comentario en 151 scripts. Control verificado: el diff no toca
NI UNA línea que no empiece por #, y la sintaxis de los 151 pasa.

El barrido saltea heredocs y cadenas triples, y el guardián DISPARÓ 3 veces:
las tres eran el MOTD que el script escribe DENTRO de la imagen construida —
texto del producto, no comentario del script. Se cambiaron aparte y a
propósito, que es rebranding, no limpieza.

Y el hallazgo caro:  casaba contra ,
que es el TARGET de tracing — o sea el module_path!, o sea el nombre del crate.
La etapa 4 lo movió a  y el script quedó casando NADA. No fallaba:
imprimía cero atribuciones, indistinguible de un log sin problemas. Comprobado
con el binario (RUST_LOG=info sobre zlib), no deducido. Ahora acepta las dos, y
tiene que seguir aceptándolas porque los logs viejos en disco dicen la vieja.

Además 14 rutas de módulo  en docs, que el barrido anterior no tocó
porque  no es frontera de palabra.

scripts/reconstruir-corpus.sh

@@ -9,13 +9,13 @@
 # la misma dirección).
 #
 # ── POR QUÉ EN SERIE, Y NO ES NEGOCIABLE ────────────────────────────────────────────────────────
-# `hammer build` comparte `work/sources/<dep>-<sha>`. Dos builds que compartan una dep se pisan el
+# `takana build` comparte `work/sources/<dep>-<sha>`. Dos builds que compartan una dep se pisan el
 # árbol y queda ROTO PARA SIEMPRE (ADR 0012, sin decidir; ~93 de 205 recetas KDE murieron así al
 # invalidar libdrm). Todo el run va bajo UN `flock work/.farm-build.lock`, el mismo que toman los
 # scripts de la granja, así que también nos serializa con ellos y con cualquier otro agente.
 #
 # ── REANUDABLE POR CONSTRUCCIÓN ─────────────────────────────────────────────────────────────────
-# No lleva estado propio: la pregunta "¿esto ya está?" se la hace al store con `hammer hash --check`
+# No lleva estado propio: la pregunta "¿esto ya está?" se la hace al store con `takana hash --check`
 # (~2 ms, sin construir). Matarlo y relanzarlo continúa donde iba. Un run entero sobre un corpus ya
 # construido son unos segundos de puros --check.
 #
@@ -52,10 +52,10 @@ SECO=0; [ "${1:-}" = "--seco" ] && SECO=1
 #
 # ── 2026-08-27: MIRA DÓNDE SE GASTA, NO DÓNDE ESTÁ EL REPO ──────────────────────────────────────
 # Medir `$ROOT` dejó de ser correcto al mudar el store al volumen `harkaq-cosecha`. `$ROOT` es
-# /mnt/vvv, que hammer COMPARTE con tawasuyu, y tawasuyu repuebla su target a ~62 G/h: el 27/08 se
+# /mnt/vvv, que takana COMPARTE con tawasuyu, y tawasuyu repuebla su target a ~62 G/h: el 27/08 se
 # comió los 92 G que se le habían liberado en 70 minutos y el vigía abortó la tanda por un disco
-# que hammer ya ni usaba. Un vigía que mide el disco de OTRO no protege la tanda, la mata.
-# Ahora se miden los tres sitios donde hammer SÍ crece —store, árboles de fuentes y CARGO_HOME—
+# que takana ya ni usaba. Un vigía que mide el disco de OTRO no protege la tanda, la mata.
+# Ahora se miden los tres sitios donde takana SÍ crece —store, árboles de fuentes y CARGO_HOME—
 # y se toma el mínimo. Si comparten FS, `df` repite el número y esto es inocuo.
 CARGO_H="${CARGO_HOME:-$HOME/.cargo}"
 # ── GOPATH TAMBIÉN CRECE, y llenó `/` hasta 0 BYTES el 2026-08-28 ───────────────────────────────
@@ -78,7 +78,7 @@ libre_gb() {
 }
 ts() { date -u +%Y-%m-%dT%H:%M:%SZ; }
 
-# EL ORDEN IMPORTA, aunque las deps se resuelvan solas. `hammer build` construye recursivamente lo
+# EL ORDEN IMPORTA, aunque las deps se resuelvan solas. `takana build` construye recursivamente lo
 # que le falta, así que cualquier orden termina — pero no cualquier orden es útil a mitad de camino.
 # Hay 1186 ficheros de receta y sólo ~440 alcanzan alguna imagen; el resto son catálogo y colas de
 # staging. Construyendo por orden alfabético, tras un día de máquina no habría NI UNA imagen
@@ -146,7 +146,7 @@ mapfile -t RECETAS < "$ORDEN"
 # ── PARTICIÓN ENTRE WORKERS: SHARD=i/N ──────────────────────────────────────────────────────────
 # Con un worker el corpus son ~7 días (medido: ~9 min/receta sobre 1161). Repartirlo es la única
 # forma de bajarlo, y no hace falta planificador central: cada worker construye SU parte y las deps
-# que le falten se las construye `hammer build` solo. Al cosechar, todo converge en el mismo store
+# que le falten se las construye `takana build` solo. Al cosechar, todo converge en el mismo store
 # porque las direcciones coinciden — eso está PROBADO por el paso 4 de `farm-lab-sync.sh`, no
 # supuesto.
 #