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

recipes/dbus-shared.toml

@@ -0,0 +1,47 @@
+# dbus-shared 1.16.2 — variante DINÁMICA (libdbus-1.so.3) para la isla dinámica de GNOME.
+#
+# El dbus canónico (recipes/dbus.toml) es `--prefer-static -Ddefault_library=static` y su
+# libdbus-1.a no es PIC. gnome-shell la alcanza por transitividad: enlaza atk-bridge-2.0, cuyo .pc
+# declara `Requires: atspi-2` y ése `Requires: dbus-1`, así que pkg-config la arrastra al enlace de
+# un binario dinámico. Sin la .so el configure ni siquiera llega a compilar — corta con
+# `Package 'dbus-1', required by 'atspi-2', not found` cuando el único dbus visible es estático.
+#
+# Es la cuarta variante -shared de esta cadena (zlib, sqlite, libxml2, libuuid + ésta) y todas por
+# la misma raíz: el corpus se construyó para un userland ESTÁTICO y el escritorio es dinámico por
+# obligación, no por gusto — la introspección de GObject exige .so reales.
+#
+# Se mantienen los apagados del canónico (systemd/x11-autolaunch/docs) y su misma versión: un solo
+# dbus en la distro, no dos protocolos conviviendo. -Dtools=true igual que el canónico para que el
+# artefacto siga trayendo dbus-daemon/dbus-run-session y pueda levantar un bus de verdad.
+name    = "dbus-shared"
+version = "1.16.2"
+license = "AFL-2.1 OR GPL-2.0-or-later"
+
+[source]
+tarball = "https://dbus.freedesktop.org/releases/dbus/dbus-1.16.2.tar.xz"
+sha256  = "0ba2a1a4b16afe7bceb2c07e9ce99a8c2c3508e5dec290dbb643384bd6beb7e2"
+
+[build]
+compiler = "zig-cc"
+target   = "x86_64-linux-musl"
+link     = "dynamic"
+flags    = []
+
+[build.phases]
+# `--wrap-mode=nodownload`: dbus declara subproyectos `.wrap` y meson intenta DESCARGARLOS. En el
+# sandbox no hay red y python no trae ssl ⇒ el error que sale no menciona la red:
+#     meson.build:372:11: ERROR: Unhandled python exception
+# Esa línea 372 es la firma del caso. Bloqueaba a `mutter`, `gnome-shell` y
+# `xdg-desktop-portal-gnome`, que la arrastran como dep — o sea que UNA flag ausente en una sombra
+# tumbaba tres raíces de perfil. La canónica del corpus y la sombra de KDE ya la tenían; éstas no.
+configure = "PYTHONPATH=/usr/lib/python3.12/site-packages meson setup output --wrap-mode=nodownload --prefix=/usr --buildtype=release -Ddefault_library=shared -Dsystemd=disabled -Dx11_autolaunch=disabled -Ddoxygen_docs=disabled -Dxml_docs=disabled -Dtools=true -Dsystem_pid_file=/run/dbus/dbus.pid"
+compile   = "PYTHONPATH=/usr/lib/python3.12/site-packages ninja -C output"
+install   = '''
+set -e
+PYTHONPATH=/usr/lib/python3.12/site-packages DESTDIR=/out meson install --no-rebuild -C output
+# can't install tmpfs
+rm -rf /out/run
+'''
+
+[deps]
+build = ["meson", "samurai", "python3", "pkgconf", "expat"]