gnome onda-1: cola aislada incoming-gnome-onda1 para el worker

Las 3 raíces de la onda 1 (gsettings-desktop-schemas, gobject-introspection,
gnome-desktop) copiadas a una cola propia + añadida al QUEUES del worker-loop.
Aislar evita que el worker dispare rebuilds de spidermonkey/mutter (onda 2/3).

El cierre real de RECETAS de las 3 es 39 nodos, 0 en incoming-kde: el "gap del
resolver" que temía era de seed-edges (.pc cairo→libX11), NO de deps declaradas.
El espinazo corpus (38 nodos: gtk4/cairo/pango/gdk-pixbuf en recipes/) está 100%
sellado ⇒ el worker cachea todo e sólo construye las 3. Hashes byte-idénticos a
los sellos de incoming-gnome (base_dir no entra al hash).

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

scripts/farm/farm-worker-loop.sh

@@ -86,7 +86,7 @@ DISK_HIGH="${DISK_HIGH:-82}"
 # aparcadas con diagnóstico, p.ej. git con muro en libgit.a) NO se muele — es un subdir a propósito.
 # incoming-clib: libs C (toolkit/foundational) que el worker SELLA pero el cron de cosecha-go IGNORA
 # (son build-deps, se usan vía catálogo; no tienen binario que el gate Go pueda smoke-testear).
-QUEUES="${QUEUES:-recipes/incoming recipes/incoming-go recipes/incoming-clib recipes/incoming-kde}"
+QUEUES="${QUEUES:-recipes/incoming recipes/incoming-go recipes/incoming-clib recipes/incoming-kde recipes/incoming-gnome-onda1}"
 
 # REBUILD DEL BINARIO AL ARRANCAR (2026-07-18): el hammer horneado en la imagen golden ENVEJECE.
 # Caso real que costó una noche de KDE: la golden del 29-jun traía un hammer sin el fix del overlay