qorpa §Orden 6: pressure-vessel ANIDA bajo la jaula — sin cuenta, sin juego y sin pantalla

El paso 6 quedaba parcial por esta frase: «pressure-vessel con un juego real
sigue sin ejercitarse», porque el runtime sniper sólo se baja al instalar un
juego y eso pide credenciales. Era un techo falso: el depot está publicado y
ahora pineado, así que se coloca a mano y la pregunta que ordenaba D6 se
responde entera.

**La evidencia**, dentro de una instancia qorpa sobre Ubuntu base, con `nesting`
y la jaula puesta:

  os-release   Ubuntu 24.04.3 LTS  →  Steam Runtime 3 (sniper)
  ns de montaje  mnt:[4026532468]  →  mnt:[4026532526]
  /usr/lib/x86_64-linux-gnu        →  675 libs de sniper, libSDL2 incluida

Contenedor de Valve anidado dentro del nuestro, con el runtime real adentro.

**Y la concesión resultó de verdad:** con `nesting = false` el mismo comando
muere en `bwrap: Creating new namespace failed: Operation not permitted`. Queda
como guardián (`scripts/qorpa/pressure-vessel-probe.sh`), que exige las DOS
mitades — sin la negativa, «no salió sniper» lo cumpliría también un cuelgue.

Tres cicatrices del camino, todas en los comentarios:

1. **`ldd --version` es la comprobación equivocada** y es la primera que uno
   escribe: pressure-vessel importa la libc del host cuando es más nueva que la
   del runtime, así que ver la glibc de afuera adentro es lo correcto y no
   prueba nada. El veredicto es `os-release`.
2. **`SALIDA=$(timeout … qorpa run …)` se cuelga para siempre** aunque timeout
   mate al hijo: la sustitución no espera al PROCESO, espera a que se cierre el
   PIPE, y pressure-vessel deja descendientes con el fd abierto. A fichero
   termina y devuelve su código.
3. **Dos `run` seguidos sobre la misma instancia fallaban** con `Can't make
   overlay mount … Device or resource busy`. El kernel niega dos overlays vivos
   con el mismo `upper` porque eso corrompe la capa — o sea que el EBUSY es un
   guardián correcto a destiempo: la corrida anterior ya devolvió el prompt y su
   namespace no terminó de reaparse. `run` reintenta acotado y, si sigue tomado,
   dice la causa en vez de soltar el mensaje crudo de bwrap.

El punto 3 salió porque el guardián exige evidencia POSITIVA de la denegación:
con «no apareció sniper» habría dado OK tapando un fallo distinto.

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

docs/adr/0015-imagenes-ajenas.md

@@ -505,6 +505,14 @@ Se escriben acá para que no se descubran en producción.
    `recreate` / `run`. El overlay lo monta bwrap (`--overlay-src` + `--overlay`) dentro de su
    propio namespace: sin root y sin montar nada en el host. `run` entra con `--clearenv` y con
    `--unshare-net` salvo que se declare `network` — el entorno del host también es una concesión.
+
+   **Corregido el mismo día, y el bug era una verdad a destiempo:** dos `run` seguidos sobre la
+   misma instancia y el segundo moría con `Can't make overlay mount … Device or resource busy`; el
+   tercero andaba. El kernel se **niega a propósito** a montar dos overlays vivos que compartan
+   `upperdir`/`workdir` —eso corrompe la capa—, así que el EBUSY es un guardián correcto: lo que
+   estaba mal era el momento, porque la corrida anterior ya devolvió el prompt y su namespace
+   todavía no terminó de reaparse. Ahora `run` reintenta acotado y, si el overlay sigue tomado,
+   dice **la causa** («¿hay otra `run` viva?») en vez de dejar pasar el mensaje crudo de bwrap.
 4. ✅ **HECHO 2026-09-03.** Concesiones → política de harkaq. `harkaq-exec` entra como último
    eslabón dentro de bwrap (cruza un binario **estático**, no una librería ⇒ D2 sigue en pie), y
    aporta lo que bwrap no da: **seccomp** —hoy una instancia podría `io_uring`, `bpf`, `ptrace`,
@@ -524,6 +532,34 @@ Se escriben acá para que no se descubran en producción.
    **Lo que NO se pudo, y por qué:** la máquina no tiene ninguna sesión gráfica (`/dev/dri` sí,
    socket Wayland no), así que Steam no dibuja; y el runtime *sniper* sólo se baja al instalar un
    juego, lo que exige credenciales. **pressure-vessel con un juego real sigue sin ejercitarse.**
+
+   **✅ AMPLIADO 2026-09-03: pressure-vessel SÍ se ejercitó — sin cuenta, sin juego y sin pantalla.**
+   Lo que lo destrabó fue pinear el depot (D8): `SteamLinuxRuntime_sniper.tar.xz` es lo que Steam
+   despliega, y colocado a mano no hace falta comprar nada. Corrido dentro de una instancia qorpa
+   *sobre Ubuntu base*, con `nesting` y la jaula puesta:
+
+   | evidencia | fuera de pressure-vessel | dentro |
+   |---|---|---|
+   | `/etc/os-release` | `Ubuntu 24.04.3 LTS` | **`Steam Runtime 3 (sniper)`** |
+   | namespace de montaje | `mnt:[4026532468]` | **`mnt:[4026532526]`** |
+   | `/usr/lib/x86_64-linux-gnu` | el de Ubuntu | **675 libs de sniper, `libSDL2-2.0.so.0` incluida** |
+
+   O sea: **contenedor de Valve anidado dentro de nuestra jaula, con el runtime real adentro.** Es
+   la pregunta que ordenaba D6 y ya no está abierta.
+
+   **Y la concesión resultó ser de verdad, no un adorno:** con `nesting = false` el mismo comando
+   muere en `bwrap: Creating new namespace failed: Operation not permitted`. Una concesión que no
+   se puede apagar no es una concesión.
+
+   Tres detalles que sólo salen corriéndolo: pressure-vessel avisa `Cannot determine ld.so for
+   i386-linux-gnu` porque Ubuntu base no trae multilib —para juegos la base es Arch, que es
+   justamente por lo que Arch está en la terna—; `ldd --version` sigue diciendo la glibc de la
+   instancia y **está bien**, porque pressure-vessel importa la libc del host cuando es más nueva
+   que la del runtime, así que la prueba de que el runtime entró es `os-release`, no `ldd`; y no
+   hay ICD de Vulkan porque no se concedió `/dev/dri` — la jaula no regala dispositivos.
+
+   **Lo que sigue faltando, y ahora es sólo esto:** un juego real dibujando, que pide sesión
+   gráfica y credenciales. Ninguna de las dos es una pregunta de diseño.
 7. ✅ **HECHO 2026-09-03.** `hammer qorpa prune` + el renglón en
    [SDD 20](../20-catalogo-publicable-y-completa.md#imágenes-ajenas-qorpa-fuera-del-catálogo-y-por-escrito).
    Poda restos de pulls a medias, imágenes que ninguna instancia usa (se re-traen por digest: es la