sergio/takana

El control que agregué en el commit anterior era el natural y estaba mal: publicar el perfil
`servidor` entero con él dejó 65 de 175 paquetes fuera, porque son LIBRERÍAS (zlib, ncurses,
openssl, musl-*, gmp…) que no traen ningún binario y existen para que otros las resuelvan como
dep — un campo que su consumidor ni mira habría tirado un tercio del repo. Lo destapó el barrido,
no el razonamiento: la versión que abortaba pasaba los tests igual.

Ahora: corrige el path si el binario quedó en otro bindir (que es el caso que importa), y si no
hay ninguno lo dice y publica igual.

Medido con el perfil `servidor`: 162 publicados y firmados, 8 con target_bin corregido (bash, sed,
tar, parted, dhcpcd, squid, wpa_supplicant, zsh — todos publicados hasta hoy prometiendo un path
que no existe), 64 sin binario, 12 sin sellar en este store, 1 fallo (os-release, ya conocido).
Contra el repo firmado por HTTP: parted (6 parches + binario en /usr/sbin) instala en 0,17 s y
responde 3.7; bash responde 5.3.0(1).

Queda vivo: `install <librería>` directo sigue fallando tras hidratar (el .swm exige que el
target_bin exista). Hacer el campo opcional toca el formato — su propia unidad de trabajo.

diff --git a/crates/takana-cli/src/main.rs b/crates/takana-cli/src/main.rs
index 9ef2638d..f57d5fb4 100644
--- a/crates/takana-cli/src/main.rs
+++ b/crates/takana-cli/src/main.rs
@@ -4009,12 +4009,19 @@ fn target_bin_verificado(
             return Ok(corregido);
         }
     }
-    anyhow::bail!(
-        "el artefacto {} no trae ningún '{bin}' en bin/, usr/bin/, sbin/, usr/sbin/ ni \
-         usr/local/bin/: el paquete prometería un binario que no existe y el `install` fallaría \
-         DESPUÉS de hidratar. Fijá el path real con --target-bin",
-        root.display()
-    )
+    // No abortamos: la mitad del perfil `servidor` son LIBRERÍAS (zlib, ncurses, openssl, musl-*)
+    // que no traen ningún binario y que se publican para que otros las resuelvan como dep — cortar
+    // acá dejaría 65 de 175 paquetes fuera del catálogo por un campo que su consumidor no mira.
+    // Pero se dice, porque `install <nombre>` DIRECTO sobre uno de ellos sí falla tras hidratar:
+    // el `.swm` exige hoy que el `target_bin` exista, y para una librería eso no tiene respuesta
+    // buena (es su propia unidad de trabajo — `target_bin` opcional toca el formato).
+    eprintln!(
+        "target_bin: el artefacto no trae ningún '{bin}' en bin/, usr/bin/, sbin/, usr/sbin/ ni \
+         usr/local/bin/ — publico '{target_bin}' igual (sirve como dependencia), pero un \
+         `install` directo de este paquete fallará DESPUÉS de hidratar. Fijalo con --target-bin \
+         si el binario existe con otro nombre."
+    );
+    Ok(target_bin)
 }
 
 /// Lee los patches declarados por la receta **en orden y uno por entrada** (nunca concatenados:
diff --git a/docs/28-servidor-de-produccion.md b/docs/28-servidor-de-produccion.md
index 0d22e81a..92741253 100644
--- a/docs/28-servidor-de-produccion.md
+++ b/docs/28-servidor-de-produccion.md
@@ -521,9 +521,35 @@ después de hidratar los 1331 ficheros**:
 Error: source_patch declara target_bin=/usr/bin/zsh pero no quedó en <prefix>/usr/bin/zsh
 ```
 
-Con `--build` el artefacto está delante: ahora `pack` comprueba el path contra él, lo corrige si el
-binario quedó en otro bindir (diciéndolo) y **aborta al publicar** si no hay ningún binario con ese
-nombre. Un paquete que promete algo que no trae no debería llegar a existir.
+Con `--build` el artefacto está delante: ahora `pack` comprueba el path contra él y lo **corrige**
+si el binario quedó en otro bindir, diciéndolo.
+
+⚠ **Y el primer intento fue abortar, que era lo natural y estaba MAL.** Al publicar el perfil
+entero con esa versión, **65 de 175 paquetes se quedaron fuera del catálogo**: son las LIBRERÍAS
+—zlib, ncurses, openssl, musl-\*, gmp…—, que no traen ningún binario y existen para que otros las
+resuelvan como dep. Un campo que su consumidor ni mira habría tirado un tercio del repo. Así que
+no aborta: avisa, y el paquete se publica. Lo mide el barrido de abajo, no el razonamiento — esa
+versión pasaba los tests igual.
+
+**Publicando el perfil `servidor` entero con el `pack` arreglado** *(medido, store del hub)*:
+
+| | |
+|---|---|
+| publicados y firmados | **162** (el índice verifica contra su `trust`) |
+| **`target_bin` corregidos** | **8: `bash` `sed` `tar` `parted` `dhcpcd` `squid` `wpa_supplicant` `zsh`** |
+| sin binario (librerías) | 64 — se publican, con aviso |
+| sin sellar en ESTE store | 12 |
+| fallaron | 1 (`os-release`, el mismo del §6.46) |
+
+Esos 8 son paquetes que **estaban publicados prometiendo un path que no existe**: `install bash`
+habría hidratado y muerto al final. Comprobado después del arreglo, contra el repo firmado servido
+por HTTP: `parted` (6 parches **y** binario en `/usr/sbin`) instala en 0,17 s y responde
+`parted (GNU parted) 3.7`; `bash` instala y responde `5.3.0(1)-release`.
+
+⚠ **Lo que queda vivo y no se tocó:** un `install <librería>` DIRECTO sigue fallando tras hidratar,
+porque el `.swm` exige que el `target_bin` exista y para una librería no hay respuesta buena. Hacer
+`target_bin` opcional toca el formato ([SDD 06](06-swm-format.md)) y es su propia unidad de trabajo.
+Como dep funcionan, que es para lo que están en el catálogo.
 
 **El lazo, después:** `takana install zsh --repo http://… --require-signed` ⇒ cache-hit del hash
 anclado, **1331 ficheros hidratados en 0,14 s**, y el binario corre (`zsh 5.9`). Antes: recompilar