publicar-repo: el vhost, con validación y vuelta atrás — y publicar deja de ser compilar

Dos cosas que el ensayo del guion destapó, las dos medidas:

1. `repo-perfil.sh` NO acotaba el build. `pack --build` es instantáneo con cache-hit y una
   compilación entera si el artefacto no está sellado, así que «publicá el repo» se convertía en
   silencio en «ponete a compilar el perfil»: la corrida se puso a moler `libnftnl` en una caja de
   4 cores que ya estaba a load 46, y después venía `rust`. `build-repo.sh` llevaba `timeout` desde
   siempre; el que se corre en producción, no. Ahora BUILD_TIMEOUT (120 s) y SKIP_UNSEALED=1, con
   el vencimiento tratado como «no estaba sellado» y no como error. Resultado del perfil entero:
   173 anclados, 0 sin ancla, 2 saltados (os-release, rust), sin compilar nada.

2. `--install-vhost` pone el bloque de Caddy sin que haya que editar a mano, pero el orden es lo
   único que lo vuelve seguro: copia → añade → `caddy validate` → SÓLO ENTONCES `reload`. Si
   validate o reload fallan, restaura la copia y recarga con ella. Un reload con la config rota no
   tira el sitio nuevo: tira los 19 de la caja.

Probado en los dos caminos contra un Caddy de juguete (el de la caja no tiene el admin abierto):
con reload bueno, el admin muestra el server nuevo sirviendo el repo y el sitio previo intacto; con
reload fallido, el Caddyfile vuelve byte a byte y no queda rastro del bloque.

Y `repo-perfil.sh` pasa a respetar TAKANA del entorno: la guarda de publicar-repo.sh comprobaba un
binario y se publicaba con otro, que es peor que no tener guarda.

docs/28-servidor-de-produccion.md

@@ -570,6 +570,25 @@ firma en `/srv/repo`, comprueba el lazo y **imprime el bloque sin tocar el Caddy
 caja Caddy sirve 19 dominios y su config ya acumula 20 `.bak`; un guion que la reescribe a ciegas es
 cómo se tiran 19 sitios para levantar uno.
 
+⚠ **Publicar no es construir, y `repo-perfil.sh` no lo acotaba.** `pack --build` es instantáneo con
+cache-hit y una **compilación entera** si el artefacto no está sellado. Medido al ensayar el guion:
+la corrida se puso a compilar `libnftnl` —y después habría seguido con `rust`— en una caja de 4
+cores que ya estaba a **load 46**. `build-repo.sh` llevaba `timeout` desde siempre; el que se corre
+en producción, no. Ahora `BUILD_TIMEOUT` (120 s) y `SKIP_UNSEALED=1`: un vencimiento **no es un
+error**, significa «ése no estaba sellado». Con eso, el perfil entero publica **173 anclados, 0 sin
+ancla, 2 saltados (`os-release`, `rust`)** sin compilar nada.
+
+**El `--install-vhost`, probado en sus dos caminos** *(con un Caddy de juguete, porque el de la caja
+no tiene el admin abierto)*:
+
+| camino | qué pasó |
+|---|---|
+| reload OK | `✓ la config valida` → `✓ recargado`; el admin muestra el `srv1` nuevo sirviendo el repo **y el sitio que ya estaba sigue en pie** |
+| reload FALLA | copia restaurada **byte a byte** (`b"repo.local" not in` el fichero final), y no recarga nada |
+
+El orden es lo único que lo hace seguro: copia → añadir → `caddy validate` → **sólo entonces**
+`reload`. Un reload con la config rota no tira el sitio nuevo: tira los 19.
+
 ⚠ **Y trae su propia guarda contra el error más fácil de cometer:** si el `takana` de la caja es
 anterior al §5.5 (se detecta porque no conoce `outdated`), **aborta antes de publicar**. Con uno
 viejo el repo sale con las 16 recetas multi-parche irreproducibles y 8 paquetes prometiendo un