puerta 5 verde: la caja publica su repo firmado y se instala de él

Estaba a medias desde el §5.4 por el lab. Con el lab instalado (§6.43), cerrada en dos movimientos,
los dos en la caja:

  publicar: 171 paquetes con expected_hash anclado, 3 sin ancla, índice verificado contra ./trust,
            firmado con la clave de release que se mudó el 16-sep. Falló uno: os-release.
  instalar: `takana install duf --require-signed --trust ./trust` ⇒ «release: trusted (by release)»,
            deps resueltas, apply OK, registrado. Bajo --prefix y --db propios, sin tocar el sistema.

⚠ El matiz honesto vale más que el verde: el artefacto YA ESTABA en el store, así que se ejercitó
resolver + verificar firma + hidratar, NO reproducir desde fuente. Lo que el lab destrabó y sí quedó
probado aparte es el HASH (§6.43, cuatro de cuatro iguales a gioser), que es donde moría antes. Queda
sin ejercitar «paquete que no está en el store» — y en una caja de producción es discutible que se
quiera: un servidor no tiene por qué compilar.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

docs/28-servidor-de-produccion.md

@@ -2701,6 +2701,44 @@ Con las dos cosas, la poda hizo su trabajo por primera vez en la caja:
 ⇒ **En total, 32,2 G recuperados hoy en la caja**: 26,8 G de artefactos superados (§6.44) y 5,4 G de
 árboles de fuentes. `/store` al 62 %, `/work` al 29 %.
 
+### 6.46 🚪 Puerta 5 verde: la caja publica su repo firmado **y se instala de él** *(2026-09-17)*
+
+La puerta 5 estaba a medias desde el §5.4 y el motivo era el de siempre: *el host no se puede
+actualizar de sí mismo porque `install` reproduce desde fuente y eso exige el LAB*. Con el lab ya
+instalado (§6.43), se cerró en dos movimientos, los dos corridos **en la caja**:
+
+**1. Publicar** — con su propia clave de release, la que se mudó el 2026-09-16 a
+`/root/.config/takana/keys/`:
+
+```
+  ==> ✓ el índice verifica contra ./trust
+  publicado: 171 con expected_hash anclado, 3 sin ancla. FALLARON: os-release
+```
+
+**2. Instalar de ese repo, en modo estricto** (`--require-signed`, que exige autoría del catálogo
+verificada y no se conforma con que el `.swm` reproduzca):
+
+```
+  release: trusted (by release)
+  install duf 0.9.1 ← dist/repo/duf-0.9.1.tkn
+  deps: resolviendo catálogo para 1 dep(s): go
+  caché: artefacto ya en el store hash=b3:abb3527d… name=duf
+  apply OK — source_patch=1 config_edit=0 init_rule=0 file_drop=0
+  registrado duf (2 fichero(s))
+```
+
+Se instaló bajo `--prefix /tmp/prueba-install` y con `--db` propio, para no tocar el sistema.
+
+⚠ **Y el matiz honesto, que vale más que el verde**: el artefacto **ya estaba en el store**, así que
+el camino que se ejercitó fue *resolver + verificar firma + hidratar*, **no** *reproducir desde
+fuente*. Lo que el lab destrabó y sí quedó probado aparte es el **hash** (§6.43: cuatro de cuatro
+iguales a gioser), que era exactamente donde moría antes —«no pude leer el apk db del lab»—. Queda
+sin ejercitar el caso «paquete que NO está en el store», que en una caja de producción además es
+discutible que se quiera: un servidor no tiene por qué compilar.
+
+⇒ `os-release` es la única receta del perfil que no se pudo publicar; es la que lleva el logo y la
+identidad de la distro, y su fallo queda anotado para mirarlo aparte.
+
 ## 7. Reusar los scripts que ya existen, y no escribir de nuevo
 
 Pedido explícito del usuario. El inventario de lo que ya hace el trabajo: