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/upgrade-e2e-test.sh

@@ -1,9 +1,9 @@
 #!/bin/sh
-# E2E de la Etapa E4 (upgrades atómicos con rollback) contra el binario `hammer` REAL.
+# E2E de la Etapa E4 (upgrades atómicos con rollback) contra el binario `takana` REAL.
 #
 # Monta un store sintético con dos árboles "producto" (v1, v2), un root FHS vivo, y ejercita:
 #   apply v1 → apply v2 → rollback → rollback, verificando el estado del root en cada paso.
-# Todo en host, sin VM: valida el cableado del CLI + la semántica generación/rollback de hammer-upgrade.
+# Todo en host, sin VM: valida el cableado del CLI + la semántica generación/rollback de takana-upgrade.
 #
 # Uso: scripts/upgrade-e2e-test.sh
 set -eu
@@ -28,8 +28,8 @@ up() { "$HAMMER" --store "$STORE" upgrade --root "$ROOT" --state-root "$STATE" -
 printf 'PRISTINE-ls' > "$ROOT/usr/bin/ls"
 printf 'motd original\n' > "$ROOT/etc/motd"
 
-# --- sella dos árboles producto sintéticos en el store (vía `hammer build`? no: usamos un mini-store
-#     a mano replicando la forma <64hex>-<name>; el of_tree lo computa hammer al aplicar) ---
+# --- sella dos árboles producto sintéticos en el store (vía `takana build`? no: usamos un mini-store
+#     a mano replicando la forma <64hex>-<name>; el of_tree lo computa takana al aplicar) ---
 seal_tree() {
     # $1=hex64 $2=name $3=builder-fn
     dir="$STORE/$1-$2"