sergio/takana

Al montar otro banco, la carga estaba en 3,34 (contra 0,13 de las cuatro cazas)
porque otro agente arrancó un cargo, y kswapd0 consumía CPU con CERO memoria
libre: recuperación de páginas bajo presión. Cada corrida mapea un libxul de
227 MB.

Es exactamente la condición que las cazas NO tenían y que los dos bancos con
cuelgues SÍ. No es prueba —el estado de aquellas ventanas no se reconstruye—
pero es la primera pista concreta, y cambia dónde buscar: cazar BAJO PRESIÓN de
memoria, no con la máquina ociosa.

diff --git a/scripts/diagnostico/cazar-cuelgue-headless.sh b/scripts/diagnostico/cazar-cuelgue-headless.sh
index ced34462..2e7af34b 100755
--- a/scripts/diagnostico/cazar-cuelgue-headless.sh
+++ b/scripts/diagnostico/cazar-cuelgue-headless.sh
@@ -28,6 +28,15 @@
 #   · Sobrevive la hipótesis que no se puede probar retroactivamente: contención transitoria de otra
 #     cosa en la máquina (es compartida con otros agentes) durante esas dos ventanas.
 #
+# ⚠ EVIDENCIA A FAVOR DE ESA HIPÓTESIS, VISTA DESPUÉS (2026-09-08): al ir a montar OTRO banco, la
+#   carga estaba en 3,34 (contra 0,13 de las cazas) porque otro agente había arrancado un `cargo`,
+#   y `kswapd0` aparecía consumiendo CPU con CERO memoria libre — o sea recuperación de páginas
+#   bajo presión. Cada corrida mapea un `libxul` de 227 MB; con la caché apretada, eso es
+#   exactamente la condición que las cuatro cazas NO tenían y que los dos bancos con cuelgues SÍ.
+#   No es prueba —no se puede reconstruir el estado de aquellas dos ventanas— pero es la primera
+#   evidencia que apunta a algo concreto: **cazar bajo presión de memoria, no con la máquina
+#   ociosa**. Se puede forzar corriendo el cazador mientras algo grande compila.
+#
 # ══ PARA QUÉ SIRVE ENTONCES ════════════════════════════════════════════════════════════════════
 # Para que la PRÓXIMA vez que aparezca, se capture en el acto en vez de empezar de cero: `wchan`,
 # `syscall` y `state` de cada proceso (distinguen espera de disco de espera de lock), memoria y