gnome: xz-shared — sin ella NINGUNA app de la imagen carga, no una

`scripts/vigia-sonames.py` sobre los cinco perfiles marcaba `liblzma.so.5` en GNOME pedido por
`libadwaita` y por `python3`. La columna de QUIÉN lo pide es la que decide, y acá decidió fuerte:
mirando el artefacto sellado, el `NEEDED` no lo lleva un binario suelto sino
**`usr/lib/libadwaita-1.so.0`**, que es la librería contra la que enlaza toda app GTK4/GNOME de la
imagen. Sin proveedor del SONAME el loader falla en TODAS, no en una.

Misma fuga de siempre —el `xz` canónico del corpus es `.a`, así que el rootfs lo resolvía contra el
sysroot Alpine DEL LAB— y por eso invisible al store: el lab no entra en `hash_inputs`.

La receta `-shared` existía sólo en `incoming-kde`. Se promueve al corpus con el mismo procedimiento
que `bzip2-shared` el 2026-09-03, y comprobando lo mismo antes de creerlo: el hash es idéntico desde
las dos rutas (b3:174289d5) ⇒ un solo artefacto y cero rebuilds. Si hubiera diferido, sería otra
receta y no valdría la promoción.

Va sólo en GNOME: en cosmic y sway ese soname lo pide únicamente `python3`, que es herramienta de
build y no viaja en la imagen.

GNOME pasa de 3 sonames sin proveedor a 2. De los dos que quedan, `libperl.so` es de `perl` (build),
y `libreadline.so.8` lo pide `usr/bin/sqlite3` —el shell de la CLI, NO `libsqlite3.so.0`—, así que
las apps están bien y lo roto es el comando. Queda anotado como verruga, no como rotura.

docs/state/targets.toml

@@ -370,6 +370,15 @@ paquetes = [
   # Arreglarlo de verdad pide re-sellar pipewire, que arrastra 7 artefactos —entre ellos dos Rust
   # que ya murieron por OOM— así que se paga el día que pipewire se re-selle por otro motivo.
   "expat-shared", "libffi-shared", "bzip2-shared", "ncurses-shared",
+  # `xz-shared` se suma el 2026-09-05, cazada por `scripts/vigia-sonames.py`. Y es la MÁS grave de
+  # todas las de esta clase encontradas hasta ahora: quien pide `liblzma.so.5` no es una herramienta
+  # ni un binario suelto, es **`libadwaita-1.so.0`** — la librería contra la que enlaza TODA app
+  # GTK4/GNOME de la imagen. Sin proveedor, el loader falla en cada una de ellas, no en una.
+  # El `xz` canónico del corpus es `.a`; la receta `-shared` existía sólo en `incoming-kde`, y se
+  # promueve al corpus igual que `bzip2-shared`: mismo hash desde las dos partes
+  # (b3:174289d5) ⇒ un solo artefacto, cero rebuilds.
+  # Sólo va acá: en cosmic y sway ese soname lo pide únicamente `python3`, que no viaja en la imagen.
+  "xz-shared",
   # ── TEMA DE ICONOS Y DE CURSORES ─────────────────────────────────────────────────────────────
   # Añadido el 2026-09-03: medido sobre los artefactos del cierre, este perfil tenía **CERO** temas
   # de iconos — ni siquiera `hicolor`. Se ve en `docs/evidencia/gnome-shell-qemu-2026-09-03-libs-

recipes/xz-shared.toml

@@ -0,0 +1,27 @@
+# xz-shared 5.8.3 — variante DINÁMICA (liblzma.so, PIC) para el escritorio KDE.
+#
+# El xz canónico (recipes/xz.toml) sella liblzma.a --disable-shared (cola static-musl). Ese .a sin PIC no
+# enlaza dentro de libarchive.so/libzip.so. Como zlib-shared/bzip2-shared, esta variante construye
+# liblzma.so con autotools --enable-shared (PIC nativo). Nombre distinto para no colisionar con el canónico.
+name    = "xz-shared"
+version = "5.8.3"
+
+[source]
+tarball = "https://github.com/tukaani-project/xz/releases/download/v5.8.3/xz-5.8.3.tar.xz"
+sha256  = "fff1ffcf2b0da84d308a14de513a1aa23d4e9aa3464d17e64b9714bfdd0bbfb6"
+
+[build]
+compiler = "zig-cc"
+target   = "x86_64-linux-musl"
+link     = "dynamic"
+flags    = []
+
+[build.phases]
+configure = '''./configure --build=$CBUILD --host=$CHOST --prefix=/usr \
+  --enable-shared --disable-static \
+  --disable-xz --disable-xzdec --disable-lzmadec --disable-lzmainfo --disable-scripts --disable-doc'''
+compile = 'make -j"$(nproc)"'
+install = "make DESTDIR=/out install && find /out -name '*.la' -delete"
+
+[deps]
+build = ["pkgconf"]