servidor: pacha y pacha-secretos suben de pin — «el llavero falló» se contaba como «no hay identidad»

Los dos daemons de `perfil.servidor` leen la seed de identidad del llavero de
sesión, y los dos tragaban el error: `.ok().flatten()` (o un `_ =>`) convierte
«no se pudo preguntar» en «no hay identidad desbloqueada». La primera es un
error de sistema; la segunda se le echa a quien está delante.

Medido en el LXC del worker, con el binario sellado que va en la imagen:
`add_key` funciona y `keyctl(KEYCTL_SEARCH)` da `ENOSYS` (seccomp de
contenedor) ⇒ ahí se puede SEMBRAR y no COSECHAR, y con la seed presente en
`/proc/keys` `pacha-secretos` igual arrancaba diciendo «SIN identidad agora
desbloqueada». Es el mismo `Err` de cualquier sistema sin llavero de kernel.

Y en `pacha-cli` era peor que un mensaje equivocado: con el llavero roto los
dotfiles se guardaban SIN CIFRAR y sin decir una palabra.

Arreglado en tawasuyu (`4f2b5eac7`) con `pacha_llavero::SeedDeSesion` —los tres
estados, con `motivo()` distinto para cada uno— y test en los dos sentidos.
`pacha-secretos` gana además `reason` en `net.tawasuyu.Secretos1`, al lado de
`persistent`, que existía justamente porque «desde afuera es indistinguible».

hash: pacha-secretos b3:1d2946d0 → b3:7599de72 · pacha b3:ea0c664f → b3:916788ae
(las dos suben juntas al mismo commit para pagar UN solo vendoreo de 2,4 G)

recipes/pacha-secretos.toml

@@ -14,9 +14,28 @@ name    = "pacha-secretos"
 version = "0.1.0"
 license = "MIT OR Apache-2.0"
 
+# ── ⚠ EL PIN SUBE, Y NO ES EL DE SUS HERMANAS (2026-09-21) ────────────────────────────────────
+# De `23a292863` a `4f2b5eac7`. El motivo es un defecto de HONESTIDAD que este servicio tenía y que
+# no se ve desde ningún guardián de ficheros (SDD 26 §7.terdecies): los lectores de la seed de
+# identidad hacían `.recuperar(…).ok().flatten()`, que convierte **«el llavero de sesión no se pudo
+# consultar»** en **«no hay identidad desbloqueada»**. La primera es un error de sistema; la segunda
+# se le echa a quien está delante. Medido en el LXC del worker: `add_key` funciona y
+# `keyctl(KEYCTL_SEARCH)` da `ENOSYS`, o sea que ahí se puede SEMBRAR y no COSECHAR — y con la seed
+# presente en `/proc/keys` este daemon igual arrancaba diciendo «SIN identidad agora desbloqueada».
+# Mismo `Err` en cualquier sistema sin llavero de kernel (el caso FreeBSD, `LlaveroError::NoSoportado`).
+#
+# Ahora `pacha-llavero::SeedDeSesion` distingue los TRES estados, el `warn!` dice cuál es, y la
+# interfaz propia `net.tawasuyu.Secretos1` gana `reason` al lado de `persistent` — que existía
+# justamente porque «desde afuera es indistinguible».
+#
+# ⚠ El pin ya NO coincide con el de `puriy-costura`, `shuma-*` y `tejido` (`23a292863`), así que
+# paga un árbol de fuentes propio (~2,4 G: se comparte por `<repo>-<sha>`). Se paga a propósito y se
+# comparte con `recipes/pacha.toml`, que sube al MISMO commit por la misma razón —su `pacha-cli`
+# guardaba los dotfiles SIN CIFRAR, en silencio, cuando el llavero fallaba—, así que las dos usan un
+# solo vendoreo. El día que las hermanas suban, que suban a éste.
 [source]
 repo   = "https://git.tawasuyu.net/tawasuyu/tawasuyu.git"
-commit = "23a292863f53b355c5c02d6185904f2c33d8ab42"
+commit = "4f2b5eac779c65eae26d6bfdb26dc5effd7ac695"
 # tawasuyu COMMITEA su propio `vendor/` (smithay parcheado, enchufado por `[patch.crates-io]` POR
 # RUTA); el `cargo vendor` de takana lo pisaría y el error habla de `taffy`, no de esto.
 cargo_vendor_dir = ".hammer-cargo-vendor"

recipes/pacha.toml

@@ -12,9 +12,28 @@ name    = "pacha"
 version = "0.1.0"
 license = "MIT OR Apache-2.0"
 
+# ── ⚠ EL PIN SUBE, Y NO ES EL DE SUS HERMANAS (2026-09-21) ────────────────────────────────────
+# De `23a292863` a `4f2b5eac7`. El motivo es un defecto de HONESTIDAD que este servicio tenía y que
+# no se ve desde ningún guardián de ficheros (SDD 26 §7.terdecies): los lectores de la seed de
+# identidad hacían `.recuperar(…).ok().flatten()`, que convierte **«el llavero de sesión no se pudo
+# consultar»** en **«no hay identidad desbloqueada»**. La primera es un error de sistema; la segunda
+# se le echa a quien está delante. Medido en el LXC del worker: `add_key` funciona y
+# `keyctl(KEYCTL_SEARCH)` da `ENOSYS`, o sea que ahí se puede SEMBRAR y no COSECHAR — y con la seed
+# presente en `/proc/keys` este daemon igual arrancaba diciendo «SIN identidad agora desbloqueada».
+# Mismo `Err` en cualquier sistema sin llavero de kernel (el caso FreeBSD, `LlaveroError::NoSoportado`).
+#
+# Ahora `pacha-llavero::SeedDeSesion` distingue los TRES estados, el `warn!` dice cuál es, y la
+# interfaz propia `net.tawasuyu.Secretos1` gana `reason` al lado de `persistent` — que existía
+# justamente porque «desde afuera es indistinguible».
+#
+# ⚠ El pin ya NO coincide con el de `puriy-costura`, `shuma-*` y `tejido` (`23a292863`), así que
+# paga un árbol de fuentes propio (~2,4 G: se comparte por `<repo>-<sha>`). Se paga a propósito y se
+# comparte con `recipes/pacha.toml`, que sube al MISMO commit por la misma razón —su `pacha-cli`
+# guardaba los dotfiles SIN CIFRAR, en silencio, cuando el llavero fallaba—, así que las dos usan un
+# solo vendoreo. El día que las hermanas suban, que suban a éste.
 [source]
 repo   = "https://git.tawasuyu.net/tawasuyu/tawasuyu.git"
-commit = "23a292863f53b355c5c02d6185904f2c33d8ab42"
+commit = "4f2b5eac779c65eae26d6bfdb26dc5effd7ac695"
 # tawasuyu COMMITEA su propio `vendor/` (smithay parcheado, enchufado por `[patch.crates-io]` POR
 # RUTA); el `cargo vendor` de takana lo pisaría y el error habla de `taffy`, no de esto.
 cargo_vendor_dir = ".hammer-cargo-vendor"