Hermano de `sway-nested.sh` para el cuarto escritorio. Levanta cosmic-comp nesteado y sus clientes;
sale con el panel entero: app-library, app-list, siete applets, pop-launcher, cosmic-toplevel y los
dos procesos del portal.
**El hallazgo, que es de la IMAGEN y no del arnés**: `/usr/lib/dri` del rootfs hidratado trae
`iris_dri.so` y NADA MÁS — el driver de Intel real. Sin `swrast_dri.so`, EGL no inicializa y
cosmic-comp muere con `Egl(InitFailed(NotInitialized))` detrás de dos `MESA-LOADER: failed to open
{zink,swrast}`. O sea que el cierre 133/133 de `escritorio-cosmic` **no puede componer en ninguna
máquina que no sea Intel** — ni en una VM, ni nesteado.
No es nuevo, es un hueco de DECLARACIÓN: `scripts/gnome/qemu-desktop-image.sh` ya lo dice en su
cabecera y copia `mesa-llvmpipe` encima con `--remove-destination`. Cada script de imagen inyecta a
mano algo que `targets.toml` no declara — justo la divergencia que `hydrate-profile.py` hace
visible. Y no se arregla declarándolo: `mesa` y `mesa-llvmpipe` instalan los MISMOS `.so`
(libEGL/libgbm/libGLESv2), así que las dos en un perfil colisionan fichero a fichero — la figura de
las dos poppler. Los scripts lo resuelven PISANDO, que es decisión de imagen y no arista de grafo.
Acá se hace lo mismo y se dice: `mesa-llvmpipe` entra como TERCER overlay, el último, o sea el de
mayor prioridad. El artefacto se elige por `hammer hash`, no por el más reciente del store.
Y `cosmic-session` no sirve para nestear: no le pasa `WAYLAND_DISPLAY` a cosmic-comp —para ella el
compositor ES el display server— y su stderr lo captura `launch_pad`, que sólo repite «cosmic-comp
exited with error code 1» y lo reinicia en bucle, así que la causa no aparece en ningún log. Por eso
el modo por defecto es `bare`: compositor a mano y clientes apuntados a SU socket.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01CGyBj4QyeCZiwLMkP9GJp6
