qorpa: el mapeo por rango — subuid + --userns FD, y el impuesto se paga

Resuelve §NO-resuelve 2 del ADR 0015, que era el ticket que más desbloqueaba.
Tres síntomas que parecían distintos —apt sin poder bajar a `_apt`, pacman sin
poder chownear a `alpm`, pressure-vessel sin poder escribir su uid_map— eran la
misma causa: bwrap crea el userns con UN SOLO id.

La cura resultó tener TRES partes, y ninguna sobra:

1. `setcap cap_setuid+ep newuidmap` (+ cap_setgid en newgidmap). shadow.toml los
   instala pero no los provisiona; sin la capability no escriben el mapa.
2. Crear el userns nosotros, mapear el rango de /etc/subuid con newuidmap y
   pasárselo a bwrap con `--userns FD`. bwrap crea el suyo con un solo id A
   PROPÓSITO y nunca llama a newuidmap: el trabajo es de quien lo invoca. El fd
   lo abre la shell (`exec 3<…`), porque un fd sólo cruza el exec si no es
   CLOEXEC y no valía la pena una dep de C para un fcntl.
3. Devolver las capabilities DENTRO del namespace. Ésta no estaba en el plan y
   es la que costó: bwrap las tira todas, y en Linux ser root es tener
   CAP_SETUID, no tener uid 0. Sin ella apt seguía sin poder seteuid(42) — un
   síntoma que parecía de subuid y no lo era. Son seguras por construcción:
   dentro de un userns sólo alcanzan lo que ese namespace posee, o sea nuestros
   propios subuid. CAP_SYS_ADMIN queda fuera y sigue colgando de `nesting`.

MEDIDO después: uid_map de 65537 ids, setgroups: allow, apt instala SIN el
APT::Sandbox::User=root, pacman sincroniza con DownloadUser=alpm INTACTO, y el
userns anidado monta con root=true ⇒ el conflicto 2 de D9 se disuelve solo.

Dos cosas más que salieron por medir, no por pensar:

- El guardián MENTÍA. qorpa-preflight envolvía al hijo en `timeout`, que forkea,
  así que newuidmap apuntaba al PID equivocado y el kernel respondía "Operation
  not permitted" — un falso negativo idéntico a un fallo real. Decía que subuid
  no andaba cuando a mano andaba. Ahora sale exit 0.
- Quitar el impuesto MUEVE el problema: el upper pasa a contener ficheros de los
  subuid (apt deja los suyos con uid 165577) que nuestro uid no puede borrar ⇒
  recreate entra a un userns mapeado para limpiar. Y cuando no hay rango, se
  degrada diciendo la causa exacta en vez de quedar en misterio.

Y un detalle que no es cosmético: `--perms 1777` antes del `--tmpfs /tmp`, o el
_apt al que apt baja no puede escribir su fichero temporal. Un /tmp que no es
1777 no es /tmp.

2 tests nuevos (el rango se lee por usuario; CAP_SYS_ADMIN NO está en las caps
de root, o `nesting` dejaría de ser una decisión). 45/45.

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

docs/adr/0015-imagenes-ajenas.md

@@ -310,12 +310,12 @@ arranca bajo Landlock** (D6). Por eso `nesting = true` cuesta la política de fi
 pesa. Nunca por defecto y siempre dicho en la línea de arranque: harkaq no afirma una jaula que no
 puso.
 
-**Conflicto 2 — `root` adentro y anidar se pelean.** Medido: con el uid remapeado a 0 (`--uid 0`), un
-userns anidado **no puede escribir su `uid_map`**. Sin remapear, anida bien pero el gestor de
-paquetes se queja. ⇒ la instancia de juegos y la de gestor de paquetes quieren mapeos **opuestos**,
-y el manifiesto lo declara (`root`, encendido por defecto). Las dos mitades se curan con lo mismo que
-el impuesto de §NO-resuelve 2: **un rango real de subuid** mapeado con `newuidmap` y pasado a bwrap
-con `--userns FD`. Ése es hoy el ticket que más desbloquea del ADR entero.
+**Conflicto 2 — ~~`root` adentro y anidar se pelean~~, RESUELTO el mismo día.** Con el userns de un
+solo id que crea bwrap, `--uid 0` impedía que un userns anidado escribiera su `uid_map`: la
+instancia de juegos y la de gestor de paquetes querían mapeos **opuestos**. Con el mapeo por rango
+de §NO-resuelve 2 el conflicto desaparece —anida **con `root = true`**, verificado— y `root` deja de
+ser una elección incómoda. El campo se queda en el manifiesto porque sigue describiendo quién sos
+adentro, no porque haya que elegir entre dos males.
 
 **Y un detalle que ordena las expectativas:** bwrap **tira todas las capabilities**, así que dentro
 de una instancia no hay `CAP_SYS_ADMIN` — el anidamiento sólo puede ser por userns sin privilegios,
@@ -334,23 +334,30 @@ Se escriben acá para que no se descubran en producción.
    capturar la pantalla y sintetizar teclas**, y el manifiesto debe decirlo en la cara del usuario.
    Cerrarlo es tarea propia y probablemente el ticket más valioso que sale de este ADR.
 
-2. **UID mapping — MEDIDO 2026-09-03, y el veredicto es mejor de lo que decía este párrafo.**
-   Sin userns privilegiados, `root` adentro es tu UID afuera. La instancia ve `uid_map: 0 1001 1` y
-   `setgroups: deny`, y eso rompe todo lo que quiera *otro* id. Medido en las dos imágenes curadas:
+2. **UID mapping — ~~el muro~~ RESUELTO 2026-09-03.** Este punto ya no describe un hueco; queda
+   por lo que enseñó. La instancia veía `uid_map: 0 1001 1` y `setgroups: deny`, y eso rompía `apt`
+   (no podía bajar a `_apt`), `pacman` (no podía chownear su descarga a `alpm`) y el userns anidado
+   de pressure-vessel. **Tres síntomas, una causa.**
 
-   | gestor | qué pasa | severidad |
-   |---|---|---|
-   | `apt` (Ubuntu 24.04) | el método http hace `setgroups` para bajar a `_apt` ⇒ `Operation not permitted` | **para**, pero se saltea con `-o APT::Sandbox::User=root`, y entonces baja 34 MB, instala y corre los triggers de dpkg enteros. Único residuo: `W: chown to root:adm … failed`, un **aviso** |
-   | `pacman` (Arch) | chownea el directorio de descarga al usuario `alpm` ⇒ `Invalid argument` | **para en duro**; con `DownloadUser` comentado sincroniza, y tras `pacman-key --init && --populate` instala y el binario corre |
+   La cura entera —`hammer qorpa run` la aplica sola cuando puede— tiene **tres partes, y ninguna
+   sobra**:
 
-   ⇒ **subuid no es un muro, es un impuesto.** Un solo id alcanza para instalar paquetes reales en
-   los dos gestores; lo que rompe es el `chown`/`setgroups` a *otro* id, y cada gestor lo hace en un
-   sitio distinto. Lo que sigue faltando para quitar el impuesto: `newuidmap`/`newgidmap` con
-   `cap_setuid`/`cap_setgid` (`recipes/shadow.toml` los INSTALA pero no los provisiona — el mismo
-   hueco espera en la distro propia) **y** una vía para que bwrap use ese mapa: bwrap crea el userns
-   con un solo id a propósito y no llama a `newuidmap`, así que hay que crear el namespace aparte,
-   mapear el rango y pasárselo con `--userns FD`. `scripts/qorpa/qorpa-preflight.sh` ya mide las dos
-   mitades.
+   | pieza | por qué |
+   |---|---|
+   | `setcap cap_setuid+ep newuidmap` (y `cap_setgid` en `newgidmap`) | el binario está en el corpus (`recipes/shadow.toml`) pero **sin provisionar**; sin la capability no puede escribir el mapa |
+   | crear el userns **nosotros**, mapear el rango de `/etc/subuid` y pasárselo a bwrap con `--userns FD` | bwrap crea el suyo con **un solo id a propósito** y nunca llama a `newuidmap`: el trabajo es de quien lo invoca |
+   | devolver las **capabilities** dentro del namespace (`--cap-add`) | **bwrap las tira todas**, y en Linux ser root es tener `CAP_SETUID`, no tener uid 0. Sin esto `apt` sigue sin poder `seteuid(42)` — un síntoma que *parecía* de subuid y no lo era |
+
+   Con las tres: `uid_map` de **65537 ids**, `setgroups: allow`, `apt` instala **sin** el
+   `APT::Sandbox::User=root`, `pacman` sincroniza con `DownloadUser = alpm` **intacto**, y el
+   userns anidado monta **con `root = true`** ⇒ el conflicto 2 de D9 se disuelve. Las capabilities
+   concedidas son seguras por construcción: dentro de un user namespace sólo alcanzan a lo que ese
+   namespace posee, o sea nuestros propios subuid. `CAP_SYS_ADMIN` queda fuera y cuelga de `nesting`.
+
+   **Y una consecuencia que sólo aparece después:** el `upper/` pasa a contener ficheros de los
+   subuid (apt deja los suyos con uid 165577) que **nuestro uid normal no puede borrar** ⇒
+   `recreate` y la poda tienen que entrar a un userns mapeado para limpiar
+   (`unshare -U --map-auto -r rm -rf`). Quitar el impuesto mueve el problema, no lo evapora.
 
 3. **Segunda cadena de suministro, sin ninguna garantía de hammer.** Sin repro, sin cierre firmado,
    sin escaneo de licencias. El riesgo no es técnico: es que se normalice. Mitigación = D5 capa 3