repo: clave de release ESTABLE y un publicador por perfil — se acabó firmar con una clave efímera

`build-repo.sh` generaba una clave nueva en cada corrida si no se le pasaba `KEY=`. Un índice firmado
con una clave que nadie conoce y que cambia cada vez no lo verifica nadie: es decoración. El SDD 19
§3.2 lo dice sin vueltas — la firma sin gestión de claves es teatro.

- `trust/release.ed25519.pub` — la clave PÚBLICA, en el repo, que es donde tiene que estar para que
  un cliente pueda verificar. La privada vive en `~/.config/takana/keys/release.ed25519` (0600),
  fuera del repo, mismo trato que las credenciales del Storage Box.
- `trust/README.md` dice también **lo que esto NO es**: no hay clave raíz fuera de línea, ni
  rotación, ni procedimiento de filtración. Cierra el agujero de la clave efímera, NO el §3.2.
- `scripts/repo-perfil.sh` publica la clausura de un perfil y **aborta si no encuentra la clave**, en
  vez de inventar una. El conjunto sale de `yupana.membresia()` sobre `targets.toml`, la misma fuente
  que usa la imagen ⇒ el repo y la imagen no pueden divergir: son la misma lista.
- Y trae su propia guarda: tras firmar, VERIFICA el índice contra `trust/` y falla si no ancla.

Medido: 88/88 del perfil `servidor` con `expected_hash` anclado, índice firmado que verifica.
Control en los dos sentidos contra el repo servido por la caja:

    --trust ./trust        => "release: trusted (by release)"     ⇒ instala
    --trust <dir vacío>    => "release: unknown-key ... clave no confiada" ⇒ ABORTA

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01RomoxEGZUhaT4pob1QSX5x

trust/README.md

@@ -0,0 +1,45 @@
+# `trust/` — la raíz de confianza del repositorio de paquetes
+
+Acá vive **la clave PÚBLICA** con la que se firma el índice del repositorio. La privada **no está en
+git y no va a estarlo**: vive en `~/.config/takana/keys/release.ed25519`, modo 0600, fuera del repo —
+el mismo trato que las credenciales del Storage Box.
+
+## Por qué existe este directorio
+
+Hasta el 2026-09-10 `scripts/build-repo.sh` firmaba con una **clave efímera**: si no se le pasaba
+`KEY=`, generaba una nueva en cada corrida. Un índice firmado con una clave que nadie conoce y que
+cambia en cada build no lo verifica nadie — es decoración. El [SDD 19 §3.2](../docs/19-lanzamiento-publico.md)
+lo dice sin vueltas: *la firma sin gestión de claves es teatro*.
+
+Con la clave estable, un cliente puede hacer:
+
+```sh
+takana install <paquete> --repo <url> --trust <ruta a este dir> --require-signed
+```
+
+y eso **falla** si el índice no está firmado por esta clave. Que falle es el punto.
+
+## ⚠ Lo que esto NO es todavía
+
+Esto cierra el agujero de la clave efímera. **No cierra el SDD 19 §3.2**, que pide tres cosas más y
+ninguna existe:
+
+1. **Una clave raíz FUERA DE LÍNEA** que firme a las de release. Hoy hay un solo nivel: si esta clave
+   se filtra, no hay nada por encima que permita revocarla y emitir otra.
+2. **Rotación**: ningún procedimiento escrito de cómo se reemplaza, ni clientes que sepan aceptar más
+   de una clave durante la transición.
+3. **Qué hacer si se filtra**: sin lo anterior, la respuesta honesta hoy es «reinstalar la confianza a
+   mano en cada cliente», que no escala más allá de nuestras propias máquinas.
+
+Mientras la distribución sea privada (SDD 28 §2, «operativo pero privado») eso es aceptable. **Antes
+de la primera descarga pública, no.**
+
+## La clave vigente
+
+| | |
+|---|---|
+| fichero | `release.ed25519.pub` |
+| algoritmo | Ed25519 |
+| creada | 2026-09-10 |
+| pública (b64) | `FRrKg+eXlFuCHUzHNMCaN7eJAesFcgVOQI8KD06IXws=` |
+| privada | `~/.config/takana/keys/release.ed25519` (0600, **nunca a git**) |

trust/release.ed25519.pub

@@ -0,0 +1 @@
+FRrKg+eXlFuCHUzHNMCaN7eJAesFcgVOQI8KD06IXws=