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/bootstrap-devfs.sh

@@ -1,5 +1,5 @@
 #!/usr/bin/env bash
-# bootstrap-devfs.sh — Prepara .dev-fs/ con todo lo que hammer-build necesita:
+# bootstrap-devfs.sh — Prepara .dev-fs/ con todo lo que takana-build necesita:
 #   1. Rootfs Alpine minirootfs como base hermética del sandbox.
 #   2. Compilador zig oficial bajo .dev-fs/tools/zig (symlink versionado).
 #   3. Build tools (make, autoconf, automake, m4, patch, coreutils, libtool,
@@ -174,7 +174,7 @@ else
     # rust 1.91.1 ⇒ techo MSRV que bloquea recetas modernas (ouch/uv 1.93, oxlint/ruff 1.94,
     # zellij 1.92). edge trae rust 1.96.0. Apuntamos los repos del rootfs a EDGE para que `apk add`
     # resuelva rust/cargo/clang 1.96 (+ arrastra gcc 15.2/musl 1.2.6/llvm22 como deps). El of_tree
-    # del 4/4 NO depende de esto (usa SWAP_RUST con el rust hammer-built); esto es el toolchain del
+    # del 4/4 NO depende de esto (usa SWAP_RUST con el rust takana-built); esto es el toolchain del
     # CATÁLOGO. OJO: edge es RODANTE y no se puede pinear —sólo publica la última versión y Alpine no
     # da snapshots datados—, así que el paso 3a-quater registra lo resuelto en un lock y AVISA de la
     # deriva. Anclar de verdad exigiría espejar APKINDEX + los .apk, que es un frente aparte.
@@ -189,7 +189,7 @@ else
     # verificación de reproducibilidad de Stage 2: con el config determinista, los applets de
     # console-tools la exigen.)
     # `bwrap git curl`: el rebuild *dentro* del builder rootfs (Stage 2 pleno, SDD 11 §7) corre
-    # hammer-build con su propio toolchain. En el host estas tres las aporta el sistema, pero en la
+    # takana-build con su propio toolchain. En el host estas tres las aporta el sistema, pero en la
     # VM el toolchain ES el único userland capaz, así que deben vivir aquí: `bwrap` anida el sandbox
     # de build, `git` rematerializa las fuentes git (git archive del mirror), `curl` baja tarballs.
     # `kmod` aporta insmod/modprobe: en la VM el sandbox de build usa overlay (módulo del kernel,
@@ -206,10 +206,10 @@ else
     # runtime, sigue en el base como tool autotools general.)
     # NOTA: `elfutils-dev` YA NO va aquí — de-Alpinizado a recipes/elfutils.toml (sólo libelf, con shims
     # musl argp/error/libintl/fts/obstack/rawmemchr), deps.build del kernel. objtool enlaza el libelf
-    # hammer desde la capa overlay. (El runtime libelf.so.1 de Alpine, si algún otro tool lo necesita,
+    # takana desde la capa overlay. (El runtime libelf.so.1 de Alpine, si algún otro tool lo necesita,
     # es la misma versión 0.194 ABI-compatible.)
     # NOTA: `openssl-dev` YA NO va aquí — de-Alpinizado a recipes/openssl.toml (libcrypto estática,
-    # deps.build del kernel). El host-tool certs/extract-cert lo enlaza desde la capa overlay hammer.
+    # deps.build del kernel). El host-tool certs/extract-cert lo enlaza desde la capa overlay takana.
     # El runtime libcrypto3/libssl3 (que curl/git necesitan) lo trae Alpine aparte, no es openssl-dev.
     # `clang-dev clang-libs`: aportan libclang.so — `bindgen` (que usan varios *-sys: libbzip3-sys,
     # etc.) lo carga en build para generar bindings de los headers C. No lo trae el base.
@@ -344,7 +344,7 @@ fi
 # linkea dinámicamente como intérprete (/lib/ld-musl-x86_64.so.1) — NO el musl target del 4/4
 # (recipes/musl.toml, estático, intacto). Reconstruimos musl 1.2.5 con 256 keys y reemplazamos el
 # loader. ABI-compat (mismo musl 1.2.5): gcc/make/etc. siguen corriendo. Seguro para of_tree: el
-# loader runtime de las tools no afecta los bytes que emiten; el 4/4 es estático contra hammer-musl.
+# loader runtime de las tools no afecta los bytes que emiten; el 4/4 es estático contra takana-musl.
 # Idempotente: si ya existe el backup .orig128, no rehace nada.
 # CRÍTICO: el loader reconstruido DEBE ser de la MISMA versión de musl que el rootfs (Alpine edge
 # es rodante: pasó de 1.2.5 a 1.2.6). Si difieren, los coreutils del rootfs (linkeados contra la