servidor: el pin de pacha/pacha-secretos sube al hijo — otro merge se llevó la arista del lock

`cargo vendor --locked` sobre `4f2b5eac7` muere con «cannot update the lock
file». Esta vez la arista que faltaba era la MÍA de esta mañana: `rpassword`
en `agora-cli`, que `338d4a9b9 "merge de git en «main» (import)"` se llevó al
resolver el lock con el lado viejo. Bisecado con `git log -S`, no adivinado.

Quinta vez que este monorepo pone el mismo muro, y ya está claro que no lo
levanta quien toca el lock sino cualquiera que toque un `Cargo.toml` — o un
merge que lo resuelva mal.

Cerrado en el worker, donde el registro está completo: +1 línea, y el blob es
byte a byte el que ya se había publicado.

hash: pacha-secretos b3:7599de72 → b3:e8038352 · pacha b3:916788ae → b3:a9fb8c17

recipes/pacha-secretos.toml

@@ -15,7 +15,10 @@ 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
+# De `23a292863` a `cd9acd0d9`, que es `4f2b5eac7` (el arreglo) más el cierre de su `Cargo.lock`:
+# `cargo vendor --locked` murió otra vez porque un `merge de git en «main» (import)` se había
+# llevado la arista `rpassword` publicada esa misma mañana — el muro no lo levanta quien toca el
+# lock sino cualquiera que toque un `Cargo.toml` del monorepo, y ya van cinco (SDD 26 §7.terdecies). 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
@@ -35,7 +38,7 @@ license = "MIT OR Apache-2.0"
 # solo vendoreo. El día que las hermanas suban, que suban a éste.
 [source]
 repo   = "https://git.tawasuyu.net/tawasuyu/tawasuyu.git"
-commit = "4f2b5eac779c65eae26d6bfdb26dc5effd7ac695"
+commit = "cd9acd0d913dd0bb74212f577b6673c7a09024cf"
 # 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

@@ -13,7 +13,10 @@ 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
+# De `23a292863` a `cd9acd0d9`, que es `4f2b5eac7` (el arreglo) más el cierre de su `Cargo.lock`:
+# `cargo vendor --locked` murió otra vez porque un `merge de git en «main» (import)` se había
+# llevado la arista `rpassword` publicada esa misma mañana — el muro no lo levanta quien toca el
+# lock sino cualquiera que toque un `Cargo.toml` del monorepo, y ya van cinco (SDD 26 §7.terdecies). 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
@@ -33,7 +36,7 @@ license = "MIT OR Apache-2.0"
 # solo vendoreo. El día que las hermanas suban, que suban a éste.
 [source]
 repo   = "https://git.tawasuyu.net/tawasuyu/tawasuyu.git"
-commit = "4f2b5eac779c65eae26d6bfdb26dc5effd7ac695"
+commit = "cd9acd0d913dd0bb74212f577b6673c7a09024cf"
 # 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"