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.

docs/adr/0010-arranque-grafo-mirada.md

@@ -110,7 +110,7 @@ muerto antes del takeover).
    hace `switch_root` a la ext4 real. Ese initrd chico es lo que destraba EFI-stub directo (el cuelgue
    del metal era por un initrd de 100MB). Validado en OVMF por `scripts/efi-disk-boot-test.sh`. (La vía
    squashfs+overlay del [post-etapa-e] queda como optimización futura; el pivote a ext4 ya cumple.)
-3. **Contrato de generaciones-grafo** ✅ (módulo `hammer_upgrade::boot_graph` + subcomando `takana
+3. **Contrato de generaciones-grafo** ✅ (módulo `takana_upgrade::boot_graph` + subcomando `takana
    boot`): el modelo in-place de generaciones se lee como un **grafo de estados** navegable (id =
    `of_tree`, DAG por `parent`), `takana boot graph` emite `/run/hammer/boot-graph.json` con el
    formato del contrato, y `takana boot activate <id>` (o `--from-select`) deja el sistema en un nodo