jaula: los builds SÍ corren adentro — el comentario mandaba a ssh por nada

Medido desde la jaula, con el hash forzado para que no hubiera caché: `anew`
(Go, estática) sella en 6,8 s y `lz4` (C, con `make install` escribiendo /out)
en 4,4 s. Con `root = false` el bwrap anidado se levanta y /proc monta.

Lo del uid 0 sigue siendo cierto para una receta cuyo `install` fije DUEÑOS, y
así queda escrito — pero no es «los builds no corren», que es lo que se leía y
lo que mandaba a pedirle cada receta al anfitrión por ssh.

scripts/servidor/claude-caja.sh

@@ -13,13 +13,14 @@
 # falta: `qorpa run` levanta la jaula con user namespaces y anda **sin privilegio**, siempre que el
 # directorio de la instancia sea del usuario.
 #
-# ⚠ LOS BUILDS SIGUEN SIN CORRER DENTRO DE LA JAULA, pero el motivo cambió y conviene tenerlo
-# medido (2026-09-18). Antes, con `root = true`, el bwrap anidado ni se levantaba: «Can't mount proc
-# on /proc». Con `root = false` **sí se levanta y /proc monta** —comprobado—, y lo que ahora falla es
-# otra cosa: el anidado **no puede mapear el uid 0** que `takana build` le pide, porque `sergio` no
-# tiene rango en `/etc/subuid` (sólo lo tiene `root`) y encima `newuidmap`/`newgidmap` **no son
-# setuid** en esta caja (`-r-xr-xr-x`). Resultado: el sandbox del build correría como 1001 y el
-# `install` que escribe `/out` con dueños se cae.
+# ⚠ Y LOS BUILDS **SÍ CORREN DENTRO DE LA JAULA** — medido el 2026-09-18 por el agente de adentro,
+# y corrige lo que decía este comentario. Dos recetas construidas y SELLADAS desde la jaula, con el
+# hash forzado para que no hubiera caché:
+#   · `anew` (Go, estática)  — fetch → `go mod vendor` → compile → sealed, 6,8 s
+#   · `lz4`  (C, estática)   — `make` + `make install` escribiendo `/out` → sealed, 4,4 s
+# Con `root = false` el bwrap anidado se levanta y `/proc` monta. Lo que NO se probó es una receta
+# cuyo `install` fije DUEÑOS: ahí sí muerde que el anidado no pueda mapear el uid 0, porque `sergio`
+# no tiene rango en `/etc/subuid` (sólo lo tiene `root`) y `newuidmap`/`newgidmap` no son setuid.
 #
 # ⚠ SE INTENTÓ CERRARLO Y **NO ALCANZÓ** (2026-09-18). Se hicieron las dos cosas obvias:
 #   · rango para `sergio` en `/etc/subuid` y `/etc/subgid` (165536:65536);