atuq §7.duodecies: el sembrador entra a las cuatro imágenes — y cifraba la seed de todos con una palabra pública

El §7.undecies dejó la bóveda declarada y a NADIE capaz de abrirla: ninguna
imagen traía un binario que sembrara `pacha_llavero::SEED_IDENTIDAD`. Esta es
esa unidad.

De las dos formas posibles entra `agora-cli`, y el motivo no es que sea mejor:
el wizard `churay-welcome-llimphi` SÍ tiene binario (medido: `src/main.rs` sin
`[[bin]]`, o sea que cargo lo descubre), pero decide además backend de IA,
dotfiles, fondo de pantalla y chasqui — la experiencia de primer arranque
entera, que no se decide dentro de una unidad del navegador.

⚠ Y antes de poder declararlo apareció lo que lo volvía imposible: sin
`AGORA_PASSPHRASE`, `Sesion::abrir()` caía en la frase de desarrollo
"agora-dev" con un aviso por stderr y un ✓ en pantalla. La cadena que eso toca:
frase → Argon2id → ChaCha20-Poly1305 que cifra la seed → la clave con la que
`boveda` descifra su base. O sea, en una imagen de escritorio, la bóveda de
todo el mundo cerrada con una palabra escrita en el fuente, y nada que falle.

Arreglado en tawasuyu (`fd08dc03a`): variable > terminal (se pregunta, sin eco,
y DOS veces en la génesis, donde un error de tipeo no se nota hasta que la seed
ya no se recupera) > desarrollo sólo si no hay a quién preguntarle. La decisión
vive en una función pura con cuatro tests, probada AL REVÉS: con el brazo
`Preguntar` borrado falla con `left: Desarrollo / right: Preguntar`.

Pin `9967b02c` → `da5fb8968` ⇒ `b3:46529e14`, 1,9 M, sellado en el worker con
la guarda PEGADA al build. Mirado por dentro (regla 3) y probado como
artefacto, con control negativo: `identity new` + `unlock` deja
`user pacha:id:default: 32` en `/proc/keys`, y con la frase equivocada contesta
«autenticación fallida» y NO re-siembra.

El muro del `Cargo.lock` por cuarta vez, con la causa cambiada: esta vez no la
puso quien tocó el lock sino otro agente que metió `shuma-taller` en un
`Cargo.toml`. Cerrado en el worker, donde el registro está completo: +1 línea.
Y el lock del árbol compartido traía otra vez el malo (índice y árbol con dos
versiones distintas, las dos rotas), así que el commit se armó con
`commit-tree` sin pasar por el índice.

Corrección al §7.undecies: el verbo es `agora-cli unlock`, no
`agora-cli identity unlock`.

El guardián de coherencia pasa de SEIS lugares a SIETE, con su cuarto control
negativo; los cuatro, en verde.

Queda: la herencia del llavero de SESIÓN entre procesos hermanos (sin medir —
y `/proc/keys` como root no la mide), y `pacha`/`pacha-secretos` en
`perfil.servidor` con el mismo hueco.

docs/state/targets.toml

@@ -352,6 +352,39 @@ paquetes = [
   # y el control de contestar que NO (§7.novies)—. Por eso entran hoy y no antes.
   "boveda",
   "shuma-pregunta",
+  # ── …Y QUIÉN SIEMBRA LA IDENTIDAD CON LA QUE ESA BÓVEDA SE ABRE (SDD 26 §7.duodecies — 2026-09-21)
+  # Declarar al dueño y al diálogo dejó la función ANDANDO y todavía IMPOSIBLE de usar, y esto se
+  # midió el mismo día. `boveda` abre su base con una clave derivada de la seed de identidad, que
+  # `pacha-boveda-llimphi` saca del llavero de SESIÓN bajo `pacha_llavero::SEED_IDENTIDAD`. En todo
+  # tawasuyu esa clave la ESCRIBEN dos binarios —`agora-cli unlock` y el wizard de
+  # bienvenida `churay-welcome-llimphi`—: el primero estaba sellado con `perfiles: []` y además
+  # pineado al 2026-06-18, donde el verbo todavía no existe; el segundo no tiene receta. ⇒ en las
+  # cuatro imágenes `abrir()` daba `Err(boveda-cerrada)` SIEMPRE, y no por falta de desbloqueo:
+  # por falta de CON QUÉ. Es la misma forma de fallo del renglón de arriba una capa más abajo, y
+  # por eso los dos bloques viven juntos: la bóveda sin dueño y el dueño sin identidad se ven igual
+  # desde el navegador — `{"ok":true,"locked":true}`, que es una respuesta exitosa.
+  #   `agora-cli`  el sembrador: `identity new --name <nombre>` crea la identidad y `unlock` la
+  #                deja en el llavero de la sesión. **1,9 M** medidos sobre el artefacto sellado
+  #                (`b3:46529e14`), contra los ~43 M de las dos de arriba. Es CLI: no tiene
+  #                lanzador ni lo necesita, así que no hay `.desktop` que comprobar acá.
+  # Medido contra el ARTEFACTO, no contra el commit (regla 3): en el worker, con el binario que va
+  # a la imagen, `identity new` + `unlock` deja `user pacha:id:default: 32` en `/proc/keys` — la
+  # seed, sus 32 bytes. Y con el control negativo puesto: con la frase equivocada contesta
+  # «autenticación fallida» y NO re-siembra.
+  # ⚠ NO es el camino de diseño y conviene que quede escrito: el de diseño es el wizard, que pide
+  # la frase en un campo en vez de en una terminal. Pero ese wizard decide además backend de IA,
+  # dotfiles, fondo de pantalla y chasqui — traerlo es decidir la experiencia de primer arranque
+  # entera, y eso no se hace de paso. Ésta hace UNA cosa y es la que el propio tawasuyu nombra como
+  # «la que siembra el login» (comentario de `pacha-secretos`).
+  # ⚠ Y queda un eslabón SIN MEDIR, dicho como tal: el llavero es el de SESIÓN
+  # (`KEY_SPEC_SESSION_KEYRING`), que lo crea el login, y en takana no lo crea nadie —`shadow`
+  # compila `--without-libpam`, así que el `login` de consola no pasa por PAM y `pam_keyinit` no
+  # corre, aunque el módulo viaje en la imagen dentro de `linux-pam`—. De ahí se SIGUE que dos
+  # procesos hermanos puedan no compartir anillo, y entonces desbloquear en una terminal no le
+  # serviría a la app lanzada desde el menú; el camino bueno sería la misma rama de procesos
+  # (desbloquear en consola y lanzar el compositor desde ahí). Eso se mide con el guardián de
+  # metal, no desde acá: `add_key` da EPERM en la jaula y `keyctl` da ENOSYS en el LXC del worker.
+  "agora-cli",
   # ── CAPTURA Y STREAMING ──────────────────────────────────────────────────────────────────────
   # `obs-studio` (2026-09-04). A diferencia de mpv, ésta vive en ESTA COLA y no en el corpus, y no
   # es preferencia: su frontend es Qt6 y las 13 recetas Qt viven sólo en `incoming-kde`. Un qtbase
@@ -657,6 +690,39 @@ paquetes = [
   # y el control de contestar que NO (§7.novies)—. Por eso entran hoy y no antes.
   "boveda",
   "shuma-pregunta",
+  # ── …Y QUIÉN SIEMBRA LA IDENTIDAD CON LA QUE ESA BÓVEDA SE ABRE (SDD 26 §7.duodecies — 2026-09-21)
+  # Declarar al dueño y al diálogo dejó la función ANDANDO y todavía IMPOSIBLE de usar, y esto se
+  # midió el mismo día. `boveda` abre su base con una clave derivada de la seed de identidad, que
+  # `pacha-boveda-llimphi` saca del llavero de SESIÓN bajo `pacha_llavero::SEED_IDENTIDAD`. En todo
+  # tawasuyu esa clave la ESCRIBEN dos binarios —`agora-cli unlock` y el wizard de
+  # bienvenida `churay-welcome-llimphi`—: el primero estaba sellado con `perfiles: []` y además
+  # pineado al 2026-06-18, donde el verbo todavía no existe; el segundo no tiene receta. ⇒ en las
+  # cuatro imágenes `abrir()` daba `Err(boveda-cerrada)` SIEMPRE, y no por falta de desbloqueo:
+  # por falta de CON QUÉ. Es la misma forma de fallo del renglón de arriba una capa más abajo, y
+  # por eso los dos bloques viven juntos: la bóveda sin dueño y el dueño sin identidad se ven igual
+  # desde el navegador — `{"ok":true,"locked":true}`, que es una respuesta exitosa.
+  #   `agora-cli`  el sembrador: `identity new --name <nombre>` crea la identidad y `unlock` la
+  #                deja en el llavero de la sesión. **1,9 M** medidos sobre el artefacto sellado
+  #                (`b3:46529e14`), contra los ~43 M de las dos de arriba. Es CLI: no tiene
+  #                lanzador ni lo necesita, así que no hay `.desktop` que comprobar acá.
+  # Medido contra el ARTEFACTO, no contra el commit (regla 3): en el worker, con el binario que va
+  # a la imagen, `identity new` + `unlock` deja `user pacha:id:default: 32` en `/proc/keys` — la
+  # seed, sus 32 bytes. Y con el control negativo puesto: con la frase equivocada contesta
+  # «autenticación fallida» y NO re-siembra.
+  # ⚠ NO es el camino de diseño y conviene que quede escrito: el de diseño es el wizard, que pide
+  # la frase en un campo en vez de en una terminal. Pero ese wizard decide además backend de IA,
+  # dotfiles, fondo de pantalla y chasqui — traerlo es decidir la experiencia de primer arranque
+  # entera, y eso no se hace de paso. Ésta hace UNA cosa y es la que el propio tawasuyu nombra como
+  # «la que siembra el login» (comentario de `pacha-secretos`).
+  # ⚠ Y queda un eslabón SIN MEDIR, dicho como tal: el llavero es el de SESIÓN
+  # (`KEY_SPEC_SESSION_KEYRING`), que lo crea el login, y en takana no lo crea nadie —`shadow`
+  # compila `--without-libpam`, así que el `login` de consola no pasa por PAM y `pam_keyinit` no
+  # corre, aunque el módulo viaje en la imagen dentro de `linux-pam`—. De ahí se SIGUE que dos
+  # procesos hermanos puedan no compartir anillo, y entonces desbloquear en una terminal no le
+  # serviría a la app lanzada desde el menú; el camino bueno sería la misma rama de procesos
+  # (desbloquear en consola y lanzar el compositor desde ahí). Eso se mide con el guardián de
+  # metal, no desde acá: `add_key` da EPERM en la jaula y `keyctl` da ENOSYS en el LXC del worker.
+  "agora-cli",
   # ── VISOR DE IMÁGENES, TAMBIÉN EN LAS CUATRO ─────────────────────────────────────────────────
   # `swayimg` y no `imv`, que era lo que proponía `docs/plan-apps-usuario-final.md`: imv dibuja con
   # OpenGL de función fija (`glBegin`/`glOrtho`) y esta distro NO tiene proveedor de GL de
@@ -1056,6 +1122,39 @@ paquetes = [
   # y el control de contestar que NO (§7.novies)—. Por eso entran hoy y no antes.
   "boveda",
   "shuma-pregunta",
+  # ── …Y QUIÉN SIEMBRA LA IDENTIDAD CON LA QUE ESA BÓVEDA SE ABRE (SDD 26 §7.duodecies — 2026-09-21)
+  # Declarar al dueño y al diálogo dejó la función ANDANDO y todavía IMPOSIBLE de usar, y esto se
+  # midió el mismo día. `boveda` abre su base con una clave derivada de la seed de identidad, que
+  # `pacha-boveda-llimphi` saca del llavero de SESIÓN bajo `pacha_llavero::SEED_IDENTIDAD`. En todo
+  # tawasuyu esa clave la ESCRIBEN dos binarios —`agora-cli unlock` y el wizard de
+  # bienvenida `churay-welcome-llimphi`—: el primero estaba sellado con `perfiles: []` y además
+  # pineado al 2026-06-18, donde el verbo todavía no existe; el segundo no tiene receta. ⇒ en las
+  # cuatro imágenes `abrir()` daba `Err(boveda-cerrada)` SIEMPRE, y no por falta de desbloqueo:
+  # por falta de CON QUÉ. Es la misma forma de fallo del renglón de arriba una capa más abajo, y
+  # por eso los dos bloques viven juntos: la bóveda sin dueño y el dueño sin identidad se ven igual
+  # desde el navegador — `{"ok":true,"locked":true}`, que es una respuesta exitosa.
+  #   `agora-cli`  el sembrador: `identity new --name <nombre>` crea la identidad y `unlock` la
+  #                deja en el llavero de la sesión. **1,9 M** medidos sobre el artefacto sellado
+  #                (`b3:46529e14`), contra los ~43 M de las dos de arriba. Es CLI: no tiene
+  #                lanzador ni lo necesita, así que no hay `.desktop` que comprobar acá.
+  # Medido contra el ARTEFACTO, no contra el commit (regla 3): en el worker, con el binario que va
+  # a la imagen, `identity new` + `unlock` deja `user pacha:id:default: 32` en `/proc/keys` — la
+  # seed, sus 32 bytes. Y con el control negativo puesto: con la frase equivocada contesta
+  # «autenticación fallida» y NO re-siembra.
+  # ⚠ NO es el camino de diseño y conviene que quede escrito: el de diseño es el wizard, que pide
+  # la frase en un campo en vez de en una terminal. Pero ese wizard decide además backend de IA,
+  # dotfiles, fondo de pantalla y chasqui — traerlo es decidir la experiencia de primer arranque
+  # entera, y eso no se hace de paso. Ésta hace UNA cosa y es la que el propio tawasuyu nombra como
+  # «la que siembra el login» (comentario de `pacha-secretos`).
+  # ⚠ Y queda un eslabón SIN MEDIR, dicho como tal: el llavero es el de SESIÓN
+  # (`KEY_SPEC_SESSION_KEYRING`), que lo crea el login, y en takana no lo crea nadie —`shadow`
+  # compila `--without-libpam`, así que el `login` de consola no pasa por PAM y `pam_keyinit` no
+  # corre, aunque el módulo viaje en la imagen dentro de `linux-pam`—. De ahí se SIGUE que dos
+  # procesos hermanos puedan no compartir anillo, y entonces desbloquear en una terminal no le
+  # serviría a la app lanzada desde el menú; el camino bueno sería la misma rama de procesos
+  # (desbloquear en consola y lanzar el compositor desde ahí). Eso se mide con el guardián de
+  # metal, no desde acá: `add_key` da EPERM en la jaula y `keyctl` da ENOSYS en el LXC del worker.
+  "agora-cli",
   # ── VISOR DE IMÁGENES, TAMBIÉN EN LAS CUATRO ─────────────────────────────────────────────────
   # `swayimg` y no `imv`, que era lo que proponía `docs/plan-apps-usuario-final.md`: imv dibuja con
   # OpenGL de función fija (`glBegin`/`glOrtho`) y esta distro NO tiene proveedor de GL de
@@ -1318,6 +1417,39 @@ paquetes = [
   # y el control de contestar que NO (§7.novies)—. Por eso entran hoy y no antes.
   "boveda",
   "shuma-pregunta",
+  # ── …Y QUIÉN SIEMBRA LA IDENTIDAD CON LA QUE ESA BÓVEDA SE ABRE (SDD 26 §7.duodecies — 2026-09-21)
+  # Declarar al dueño y al diálogo dejó la función ANDANDO y todavía IMPOSIBLE de usar, y esto se
+  # midió el mismo día. `boveda` abre su base con una clave derivada de la seed de identidad, que
+  # `pacha-boveda-llimphi` saca del llavero de SESIÓN bajo `pacha_llavero::SEED_IDENTIDAD`. En todo
+  # tawasuyu esa clave la ESCRIBEN dos binarios —`agora-cli unlock` y el wizard de
+  # bienvenida `churay-welcome-llimphi`—: el primero estaba sellado con `perfiles: []` y además
+  # pineado al 2026-06-18, donde el verbo todavía no existe; el segundo no tiene receta. ⇒ en las
+  # cuatro imágenes `abrir()` daba `Err(boveda-cerrada)` SIEMPRE, y no por falta de desbloqueo:
+  # por falta de CON QUÉ. Es la misma forma de fallo del renglón de arriba una capa más abajo, y
+  # por eso los dos bloques viven juntos: la bóveda sin dueño y el dueño sin identidad se ven igual
+  # desde el navegador — `{"ok":true,"locked":true}`, que es una respuesta exitosa.
+  #   `agora-cli`  el sembrador: `identity new --name <nombre>` crea la identidad y `unlock` la
+  #                deja en el llavero de la sesión. **1,9 M** medidos sobre el artefacto sellado
+  #                (`b3:46529e14`), contra los ~43 M de las dos de arriba. Es CLI: no tiene
+  #                lanzador ni lo necesita, así que no hay `.desktop` que comprobar acá.
+  # Medido contra el ARTEFACTO, no contra el commit (regla 3): en el worker, con el binario que va
+  # a la imagen, `identity new` + `unlock` deja `user pacha:id:default: 32` en `/proc/keys` — la
+  # seed, sus 32 bytes. Y con el control negativo puesto: con la frase equivocada contesta
+  # «autenticación fallida» y NO re-siembra.
+  # ⚠ NO es el camino de diseño y conviene que quede escrito: el de diseño es el wizard, que pide
+  # la frase en un campo en vez de en una terminal. Pero ese wizard decide además backend de IA,
+  # dotfiles, fondo de pantalla y chasqui — traerlo es decidir la experiencia de primer arranque
+  # entera, y eso no se hace de paso. Ésta hace UNA cosa y es la que el propio tawasuyu nombra como
+  # «la que siembra el login» (comentario de `pacha-secretos`).
+  # ⚠ Y queda un eslabón SIN MEDIR, dicho como tal: el llavero es el de SESIÓN
+  # (`KEY_SPEC_SESSION_KEYRING`), que lo crea el login, y en takana no lo crea nadie —`shadow`
+  # compila `--without-libpam`, así que el `login` de consola no pasa por PAM y `pam_keyinit` no
+  # corre, aunque el módulo viaje en la imagen dentro de `linux-pam`—. De ahí se SIGUE que dos
+  # procesos hermanos puedan no compartir anillo, y entonces desbloquear en una terminal no le
+  # serviría a la app lanzada desde el menú; el camino bueno sería la misma rama de procesos
+  # (desbloquear en consola y lanzar el compositor desde ahí). Eso se mide con el guardián de
+  # metal, no desde acá: `add_key` da EPERM en la jaula y `keyctl` da ENOSYS en el LXC del worker.
+  "agora-cli",
   # `dunst` es LA OTRA MITAD, y sólo hace falta acá: KDE la atiende con plasma-workspace, GNOME con
   # gnome-shell y COSMIC con cosmic-notifications; sway no tenía a NADIE escuchando
   # `org.freedesktop.Notifications`, así que una página que pedía notificar mandaba el mensaje al bus