atuq: la bóveda del navegador contesta CERRADA — faltaban el dueño y el diálogo, no el guardián

El §7.quinquies.bis cerró la unidad 12 diciendo que el guardián de METAL «ahora sí se puede escribir
porque hay con qué correrlo». No se podía, y la primera pregunta que ese guardián iba a hacer lo dice
en veinte segundos, contra el artefacto sellado y por marcos de 4 bytes:

    ← {"id":1,"ok":true,"verb":"ping","version":"0.1.0"}          ← el control: el host ESTÁ
    ← {"id":2,"ok":true,"verb":"vault.status","locked":true,...}
    ← {"id":3,"ok":true,"verb":"vault.match","locked":true,"items":[]}
    stderr: puriy-costura: sin bóveda (No such file or directory): los verbos vault.* dirán «cerrada»

Lo que engaña es el `ok:true`: **«cerrada» es una respuesta exitosa**, así que ningún log, ningún
reintento y ninguna insignia la distinguen de un usuario que todavía no desbloqueó la suya. Hoy, en
las cuatro imágenes de escritorio, atuq instala la décima extensión y la función está apagada.

Las dos mediciones del §7.quinquies eran correctas y lo siguen siendo —`strings` da `vault` 10 veces,
`vigia-atuq-verbos` da cero verbos sin dueño—, pero las dos preguntan si el host CONOCE el verbo.
Ninguna pregunta quién contesta del otro lado del socket: el host no abre la bóveda nunca, a propósito
(sled toma un lock exclusivo y el proceso que lanza el navegador muere con cada pestaña), así que le
habla a un DUEÑO — y el dueño no estaba en el corpus. Saber el verbo no es poder contestarlo.

Entran las dos piezas que faltaban, las dos con el mismo efecto de «se ve apagado y nada falla»:
`boveda` (pacha-boveda-llimphi, el dueño único de la base, que levanta el socket del navegador) y
`shuma-pregunta` (el diálogo que lanza `PorDialogo`; sin él `Command::new` falla y **todo vault.fill
se deniega**, indistinguible de que el usuario haya dicho que no).

Las dos pineadas al MISMO 23a292863 que ya comparten puriy-costura, shuma-* y pacha-* —un pin
distinto es otro vendoreo de 2,4 G— y con la forma de mirada-greeter, que es el patrón de una llimphi
GUI: link dinámico (winit/wgpu dlopean EGL/Vulkan/wayland) y la inyección de LOCKSTEP_XML_PATH que
evita el panic de zbus-lockstep-macros en el subdir xml/schemas/ de atspi.

⚠ El sello TODAVÍA NO ESTÁ: las dos están encoladas en el worker detrás del build de rust, bajo
`flock -o`. Hasta que sellen, estas recetas son una hipótesis escrita, no un artefacto medido.

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

recipes/boveda.toml

@@ -0,0 +1,88 @@
+# boveda — la app de la bóveda de la suite, y **el dueño único** de su base (SDD-BOVEDA §8.5).
+#
+# ── POR QUÉ ESTA RECETA, Y POR QUÉ RECIÉN AHORA (2026-09-18) ────────────────────────────────────
+# `atuq` trae desde el 2026-09-15 la extensión `boveda@atuq.tawasuyu` —la décima— y desde el
+# 2026-09-16 el host `puriy-costura` pineado a un commit que SÍ atiende `vault.*`. Con eso el SDD 26
+# (§7.quinquies.bis) dio la unidad 12 por destrabada y anunció que «ahora sí se puede escribir el
+# guardián de metal porque hay con qué correrlo».
+#
+# ⚠ **Y no había.** Medido contra el artefacto sellado, en esta máquina, con el binario que va en la
+# imagen:
+#
+#     ← {"id":2,"ok":true,"verb":"vault.status","locked":true,"count":0}
+#     ← {"id":3,"ok":true,"verb":"vault.match","locked":true,"items":[]}
+#     stderr: puriy-costura: sin bóveda (No such file or directory (os error 2)):
+#             los verbos vault.* dirán «cerrada»
+#
+# El host **nunca abre la bóveda por su cuenta, a propósito**: `sled` toma un lock exclusivo, y el
+# proceso que lanza el navegador muere y revive con cada pestaña, así que no es un buen dueño de la
+# base. El host le habla al DUEÑO por un socket… y el dueño no estaba en el corpus. O sea que la
+# función que el navegador anuncia —insignia, `vault.match`, `vault.fill`— hoy contesta «cerrada»
+# en las cuatro imágenes de escritorio, sin un solo error a la vista. Es exactamente la forma de
+# fallo que el §7.quinquies describe: ficheros en orden, navegador sin la función.
+#
+# El dueño es ESTA app: abre la bóveda para su propia ventana y levanta el socket en un hilo para
+# el navegador (`atender_al_navegador`), con políticas distintas de cada lado — sin preguntar a
+# quien está mirando la ventana, preguntando SIEMPRE a lo que llega de afuera (`PorDialogo`, que
+# lanza `shuma-pregunta`; ver `recipes/shuma-pregunta.toml`, sin la cual todo `vault.fill` se
+# deniega).
+#
+# ── LA FORMA DE LA RECETA ──────────────────────────────────────────────────────────────────────
+# Es una llimphi GUI del monorepo: el patrón es `mirada-greeter` (winit + wgpu/vello ⇒ `link =
+# "dynamic"`, porque EGL/Vulkan/wayland se cargan por `dlopen` en runtime y `crt-static` lo
+# impediría) sobre el pin `23a292863`, que es el que ya comparten `puriy-costura`, `shuma-*`,
+# `pacha-*` y `tejido`: **un pin distinto es otro vendoreo de 2,4 G**, no un detalle de gusto.
+name    = "boveda"
+version = "0.1.0"
+license = "MPL-2.0"
+
+[source]
+repo   = "https://git.tawasuyu.net/tawasuyu/tawasuyu.git"
+commit = "23a292863f53b355c5c02d6185904f2c33d8ab42"
+# tawasuyu COMMITEA su propio `vendor/` (smithay parcheado por `[patch.crates-io]` POR RUTA); el
+# `cargo vendor` de takana lo pisaría y el error hablaría de un crate cualquiera, no de esto.
+# No entra en `hash_inputs`.
+cargo_vendor_dir = ".hammer-cargo-vendor"
+
+[build]
+compiler = "zig-cc"
+target   = "x86_64-linux-musl"
+link     = "dynamic"
+flags    = ["-p", "pacha-boveda-llimphi", "--bin", "boveda"]
+
+# Fase `compile` EXPLÍCITA —réplica de la que takana genera para Cargo— porque hay que inyectar
+# `LOCKSTEP_XML_PATH` ANTES del build. La causa está escrita entera en `mirada-greeter.toml` y es
+# la misma acá, con el mismo `accesskit_winit` 0.33 y el mismo `zbus-lockstep-macros` 0.5.2 en el
+# lock: su `#[validate]` escanea el dir `xml/` de `atspi-common` llamando `.extension().expect()`
+# en CADA entrada ⇒ PANICA en el subdirectorio `xml/schemas/`. Apuntando la variable a un dir con
+# sólo los `.xml` se evita.
+#
+# ⚠ La ruta NO es `vendor/` como en `mirada-greeter`: con `cargo_vendor_dir` los crates vendoreados
+# caen en `.hammer-cargo-vendor/`. Y la comprobación es a GRITOS: si mañana `atspi-common` deja de
+# vendorearse ahí, un `cp` que falla en silencio dejaría la variable apuntando a un dir vacío y el
+# panic volvería con el error lejos de la causa.
+[build.phases]
+compile = '''
+set -e
+XMLDIR="$PWD/.atspi-lockstep-xml"
+mkdir -p "$XMLDIR"
+ls .hammer-cargo-vendor/atspi-common/xml/*.xml >/dev/null 2>&1 || { echo "no hay .hammer-cargo-vendor/atspi-common/xml/*.xml — ¿cambió el vendoreo o la versión de atspi? sin esto zbus-lockstep-macros panica en xml/schemas/" >&2; exit 1; }
+cp .hammer-cargo-vendor/atspi-common/xml/*.xml "$XMLDIR"/
+export LOCKSTEP_XML_PATH="$XMLDIR"
+printf '%s\n' '#!/bin/sh' 'for a do' 'case "$a" in --target=*) a=--target=x86_64-linux-musl ;; esac' 'set -- "$@" "$a"' 'shift' 'done' 'exec zig cc -mcpu=baseline "$@"' > "$PWD/.hammer-zig-cc"
+chmod +x "$PWD/.hammer-zig-cc"
+RF="-C linker=$PWD/.hammer-zig-cc"
+rustc -vV | grep -q 'host: .*-alpine-' || RF="$RF -C link-self-contained=no"
+CC="$PWD/.hammer-zig-cc" RUSTFLAGS="$RF" cargo rustc --release --locked --offline -p pacha-boveda-llimphi --bin boveda -- -C target-feature=-crt-static
+'''
+install = '''
+set -e
+test -x target/release/boveda || { echo "no hay target/release/boveda — ¿cambió el nombre del bin en pacha-boveda-llimphi?" >&2; exit 1; }
+install -Dm755 target/release/boveda /out/usr/bin/boveda
+'''
+
+[deps]
+# Las mismas que `mirada-greeter` menos `linux-pam` (eso era de `auth-core`, que esta app no usa:
+# su segundo factor es `nakui-auth`, Rust puro). El stack gráfico se consulta en build-time por
+# pkg-config y se carga por `dlopen` en runtime.
+build = ["mesa", "wayland", "wayland-protocols", "libdrm", "expat", "zlib", "zstd", "libffi", "pkgconf"]