sergio/takana

El `echo "ciclo: N recetas en $Q"` sale ANTES de pedir el lock, así que con la campaña corriendo el
journal mostraba el anuncio del ciclo y después nada: parece un loop trabajando y es un loop
bloqueado. Es la misma clase de problema que el "no encuentro el ejecutable zig" apuntando al
directorio equivocado — un log que miente cuesta horas de diagnóstico.

`flock -n` primero, y sólo si falla se anuncia la espera y se bloquea. Sin coste cuando el lock
está libre, que es el caso normal.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

diff --git a/scripts/farm/farm-worker-loop.sh b/scripts/farm/farm-worker-loop.sh
index 28ce1fd5..f5c616fa 100755
--- a/scripts/farm/farm-worker-loop.sh
+++ b/scripts/farm/farm-worker-loop.sh
@@ -110,7 +110,17 @@ while :; do
     # (LOCK_WAIT) y sale limpia si no entra, en vez de colgarse.
     # NO cubre el `-P2` interno: dos recetas de la MISMA cola que compartan dep siguen pudiendo
     # pisarse. Ese es el arreglo de fondo, un lock por árbol dentro de `fetch`.
-    ( flock 9; JOBS="$JOBS" PROMOTE=0 QUEUE="$Q" scripts/build-farm.sh 2>&1 | tail -50 ) 9>"$LOCK_FARM"
+    # El `flock -n` primero es sólo para poder DECIR que estamos esperando: si el log dijera
+    # "ciclo: N recetas" y después nada, parecería que el loop trabaja cuando en realidad está
+    # bloqueado, y ese malentendido es exactamente el que cuesta horas de diagnóstico.
+    (
+      if ! flock -n 9; then
+        echo "$(date -u +%FT%TZ) esperando el lock de build (campana-deuda lo tiene)…"
+        flock 9
+        echo "$(date -u +%FT%TZ) lock tomado, sigo con $Q"
+      fi
+      JOBS="$JOBS" PROMOTE=0 QUEUE="$Q" scripts/build-farm.sh 2>&1 | tail -50
+    ) 9>"$LOCK_FARM"
   done
   if [ "$total" -gt 0 ]; then
     echo "$(date -u +%FT%TZ) ciclo terminado; store sellado disponible para el hub"