corpus: subir nasm, alsa-lib y ffmpeg desde las colas — los tres con hash idéntico

Primer paso del frente de apps (ADR 0015, montón A: mpv → OBS → Firefox). `mpv` va al corpus
porque lo quieren las cuatro imágenes, y una receta del corpus resuelve sibling-first en
`recipes/`: desde ahí NO alcanza `incoming-kde/` ni `incoming-cosmic/`. Sus tres deps de sistema
vivían sólo en colas.

Lo que hace que esto no sea duplicar: `hammer hash` da el MISMO ArtifactHash a cada par
(nasm b3:3624bdd8, alsa-lib b3:73fb200a, ffmpeg b3:bfef7bf3), porque las deps que las colas les
resolvían ya caían al catálogo padre. Cache hit, cero rebuild, y una imagen que arrastre las dos
recetas hidrata UN artefacto en vez de dos peleando por la misma ruta.

Verificado también que comentar la receta es gratis: las cabeceras nuevas no mueven el hash.

recipes/alsa-lib.toml

@@ -0,0 +1,41 @@
+# ══ COPIA AL CORPUS, hash IDÉNTICO (b3:73fb200a…) ════════════════════════════════════
+# El original nació en `incoming-kde/` y ya fue copiado a `incoming-gnome/` y `incoming-cosmic/` por
+# la misma razón que sube ahora al corpus: **una receta sólo alcanza su propia cola y el catálogo
+# padre**, nunca una cola hermana. `mpv` vive en el corpus y necesita `alsa.pc`.
+#
+# GRATIS, MEDIDO: su única dep es `pkgconf`, que ya resolvía al catálogo PADRE desde las tres colas
+# ⇒ el cierre no cambia y `hammer hash` da el MISMO ArtifactHash a los cuatro ficheros. Un solo
+# artefacto en el store, hidrate quien hidrate.
+#
+# ⚠ QUÉ SIGNIFICA ESTO PARA EL SONIDO DE VERDAD, que no es obvio: el servidor de audio de la distro
+# es PipeWire (decisión del usuario, 2026-07-29), y las tres recetas de pipewire llevan HOY
+# `-Dpipewire-alsa=disabled`. O sea que un cliente ALSA **no** desemboca en PipeWire: abre la tarjeta
+# por su cuenta y compite con él. Mientras eso no se invierta, `mpv --ao=alsa` suena en una máquina
+# sin PipeWire corriendo y choca en una con él. Está escrito en `recipes/mpv.toml` y es el próximo
+# paso del frente, no un olvido.
+# alsa-lib 1.2.14 — API de audio del kernel Linux (libasound.so). Campaña KDE (ADR 0011): sustrato de
+# PulseAudio → pulseaudio-qt → plasma-pa (el applet de volumen). Primer eslabón de la cadena de AUDIO real
+# (hasta ahora el lab sólo tenía libcanberra con backend NULL, sin reproducción).
+#
+# --disable-python: los bindings pyalsa exigen headers de python + no hacen falta. Sin deps externas.
+name    = "alsa-lib"
+version = "1.2.14"
+license = "LGPL-2.1-or-later"
+
+[source]
+tarball = "https://www.alsa-project.org/files/pub/lib/alsa-lib-1.2.14.tar.bz2"
+sha256  = "be9c88a0b3604367dd74167a2b754a35e142f670292ae47a2fdef27a2ee97a32"
+
+[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-python'
+compile   = 'make -j"$(nproc)"'
+install   = "make DESTDIR=/out install && find /out -name '*.la' -delete"
+
+[deps]
+build = ["pkgconf"]

recipes/ffmpeg.toml

@@ -0,0 +1,71 @@
+# ══ COPIA AL CORPUS, hash IDÉNTICO (b3:bfef7bf3…) ════════════════════════════════════
+# El original vive en `incoming-kde/` porque entró por kpipewire (grabar streams). Sube al corpus
+# porque `mpv` lo necesita y una receta del corpus no alcanza una cola hermana.
+#
+# GRATIS Y SIN DUPLICAR, medido con `hammer hash` antes de escribir esto: sus dos deps son `pkgconf`
+# y `zlib-shared`; `incoming-kde/zlib-shared.toml` y `recipes/zlib-shared.toml` son el mismo texto
+# (difieren en una línea en blanco, que no entra a `hash_inputs`) ⇒ el cierre no cambia y los dos
+# ficheros dan el MISMO ArtifactHash. Una imagen KDE con mpv adentro hidrata UN ffmpeg.
+#
+# ⚠ LO QUE ESTA COPIA HEREDA Y `mpv` PAGA: `--disable-x86asm`. Para kpipewire —que sólo codifica un
+# stream de escritorio— da igual; para un reproductor de video es la diferencia entre decodificar con
+# SIMD y decodificar sin ella. Se deja ASÍ A PROPÓSITO: cambiarlo acá produciría un ffmpeg con hash
+# distinto al de `incoming-kde/`, y entonces sí habría DOS ffmpeg peleando por las mismas rutas en
+# una imagen KDE. El arreglo correcto no es esta receta sino promover una sola ffmpeg con x86asm y
+# jubilar la de la cola —cambio con radio propio, que se mide antes de hacerlo. `nasm` ya está en el
+# corpus para cuando toque.
+# ffmpeg 7.1 — libavcodec/libavutil/libavformat/libavfilter (+swscale/swresample). Campaña KDE (ADR 0011):
+# **kpipewire** los exige los cuatro REQUIRED (`pkg_check_modules(AVCodec ... libavcodec REQUIRED)` etc.)
+# para KPipeWireRecord (grabar streams a fichero), y spectacle linkea K::KPipeWireRecord duro.
+#
+# ffmpeg NO usa autotools: trae su propio `configure` con --cc/--ar/--nm/--ranlib. Se le pasan wrappers de
+# UN SOLO TOKEN (`$PWD/.zwrap/*`): un `--ar="zig ar"` con espacio se ejecutaría como un binario único
+# (mismo gotcha que el AR de los crates `cc` en las recetas Rust).
+#
+# **--disable-autodetect** es clave para el determinismo: sin él, configure escanea el sandbox y activa
+# libs a discreción. Con él, ffmpeg queda auto-contenido (sus códecs nativos, sin x264/x265/vpx/etc.).
+# Sin programas (ffmpeg/ffplay/ffprobe) ni doc: kpipewire sólo consume las libs.
+name    = "ffmpeg"
+version = "7.1"
+
+[source]
+tarball = "https://ffmpeg.org/releases/ffmpeg-7.1.tar.xz"
+sha256  = "40973d44970dbc83ef302b0609f2e74982be2d85916dd2ee7472d30678a7abe6"
+
+[build]
+compiler = "zig-cc"
+target   = "x86_64-linux-musl"
+link     = "dynamic"
+flags    = []
+
+[build.phases]
+configure = '''
+ZW="$PWD/.zwrap"; mkdir -p "$ZW"
+cat > "$ZW/cc" <<'W'
+#!/bin/sh
+exec /opt/zig/zig cc -mcpu=baseline "$@"
+W
+cat > "$ZW/cxx" <<'W'
+#!/bin/sh
+exec /opt/zig/zig c++ -mcpu=baseline "$@"
+W
+cat > "$ZW/ar" <<'W'
+#!/bin/sh
+exec /opt/zig/zig ar "$@"
+W
+cat > "$ZW/ranlib" <<'W'
+#!/bin/sh
+exec /opt/zig/zig ranlib "$@"
+W
+chmod +x "$ZW/cc" "$ZW/cxx" "$ZW/ar" "$ZW/ranlib"
+./configure --prefix=/usr \
+  --cc="$ZW/cc" --cxx="$ZW/cxx" --ar="$ZW/ar" --ranlib="$ZW/ranlib" \
+  --enable-shared --disable-static \
+  --disable-autodetect --disable-doc --disable-programs --disable-debug \
+  --disable-x86asm
+'''
+compile = 'make -j"$(nproc)"'
+install = "make DESTDIR=/out install"
+
+[deps]
+build = ["pkgconf", "zlib-shared"]

recipes/nasm.toml

@@ -0,0 +1,34 @@
+# ══ COPIA AL CORPUS, hash IDÉNTICO (b3:3624bdd8…) ═══════════════════════════════════════════════
+# El original vive en `incoming-cosmic/` (y una copia gemela en `incoming-gnome/`) porque nació
+# como build-dep de mozjs. Sube al corpus porque `libass` —y detrás `mpv`— lo necesitan, y una
+# receta del corpus resuelve sus deps sibling-first en `recipes/`: desde acá no alcanza a
+# `incoming-cosmic/`.
+#
+# LA COPIA ES GRATIS Y NO DUPLICA NADA, y eso hay que medirlo antes de creerlo: su única dep es
+# `make`, que en `incoming-cosmic/` ya resolvía al catálogo PADRE, así que el cierre no cambia y
+# `hammer hash` da el MISMO ArtifactHash a los dos ficheros. Consecuencia práctica: una imagen que
+# arrastre las dos recetas hidrata UN solo artefacto, no dos que compiten por la misma ruta —que es
+# el cuadro que costó el episodio de las dos glib.
+# nasm — ensamblador x86. Herramienta de BUILD de mozjs (algunas rutas de código generan .asm) y de
+# varias libs de media más adelante. No está en el rootfs Alpine ni tenía receta. C plano, autotools.
+name    = "nasm"
+version = "2.16.03"
+license = "BSD-2-Clause"
+
+[source]
+tarball          = "https://www.nasm.us/pub/nasm/releasebuilds/2.16.03/nasm-2.16.03.tar.xz"
+sha256           = "1412a1c760bbd05db026b6c0d1657affd6631cd0a63cddb6f73cc6d4aa616148"
+strip_components = 1
+
+[build]
+compiler = "gcc"
+target   = "x86_64-linux-musl"
+link     = "static"     # binario de herramienta: estático, sin runtime que arrastrar
+
+[build.phases]
+configure = "./configure --build=$CBUILD --host=$CHOST --prefix=/usr"
+compile   = "make -j\"$(nproc)\""
+install   = "make DESTDIR=/out install"
+
+[deps]
+build = ["make"]