fix: el checklist normalizaba un swap alto que no era normal

Decía 'Normal en nodos con índice completo' ante un swap al 99%. En el caso
real que lo destapó no lo era: Fulcrum tenía db_mem a 16 GB, más de lo que
cabe en la máquina, y el sistema llevaba quince días sin margen ante un pico
de memoria. Ese mensaje es la razón de que se ignorara tanto tiempo.

Umbral del 95% al 50%, error por encima del 80%, detección del caso 'swap
alto con RAM libre' (firma de memoria sobrerreservada), y el aviso apunta a
db_mem e incluye el comando para ver quién ocupa el swap.

CHANGELOG.md

@@ -12,6 +12,22 @@ y el versionado sigue [Versionado Semántico](https://semver.org/lang/es/):
 
 ---
 ## [1.13.0] — 2026-08-08
+### Cambiado
+- **El checklist decía que un swap alto era "normal en nodos con índice
+  completo".** No lo es, y decirlo hace que se ignore durante semanas un
+  síntoma con causa y con arreglo. El caso que lo cambió: swap al 99% con 18 GB
+  de RAM libre, porque Fulcrum tenía `db_mem` a 16 GB — más de lo que cabe en
+  la máquina junto al resto de servicios. Con el swap lleno el sistema se queda
+  sin margen y, ante un pico, el OOM killer elige él a quién mata.
+  - El umbral baja del 95% al 50%, que es cuando conviene mirarlo y no cuando
+    ya es tarde, y pasa a estado de error por encima del 80%.
+  - Si el swap sube **teniendo RAM libre**, el aviso lo señala: es la firma de
+    un servicio con más memoria reservada de la que cabe, no de presión real.
+  - Apunta al sospechoso habitual (`db_mem` de Fulcrum, que se sube para
+    acelerar la sincronización inicial y es fácil olvidarse de bajar) e incluye
+    el comando para ver qué proceso ocupa el swap.
+- Misma corrección en la explicación de SWAP de los DOCS.
+
 ### Añadido
 - **Nueva comprobación: direcciones que quedan vinculadas entre sí.** Era el
   hueco de fondo del analizador: medía la privacidad desde el lado de quien

dashboard.html

@@ -3030,14 +3030,31 @@
         }
 
         // ── 5. Swap alto ──────────────────────────────────────────────
-        if (sysData?.swap) {
+        // Este aviso decía antes que un swap alto era "normal en nodos con
-          const pct = sysData.swap.percent || 0;
+        // índice completo". No lo es, y decirlo hace que se ignore durante
+        // semanas un síntoma que sí tiene causa y sí tiene arreglo. El caso
+        // real que lo cambió: swap al 99% con 18 GB de RAM libre, porque
+        // Fulcrum tenía db_mem configurado a 16 GB — más de lo que cabe en la
+        // máquina junto al resto de servicios. Con el swap lleno, el sistema
+        // se queda sin margen y ante un pico actúa el OOM killer, que elige
+        // él a quién mata.
+        //
+        // El umbral baja a 50% porque a partir de ahí ya conviene mirarlo, no
+        // cuando queda un 5% libre y es tarde.
+        const swapStats = sysData?.swap || (sysData?.ram ? { percent: sysData.ram.swap_percent, used_gb: sysData.ram.swap_used_gb } : null);
+        if (swapStats) {
+          const pct = swapStats.percent || 0;
+          const ramLibre = sysData?.ram?.free_gb;
+          // Swap ocupado teniendo RAM libre es la firma de un servicio con más
+          // memoria reservada de la que cabe: el kernel apartó páginas y no las
+          // devuelve por su cuenta.
+          const conRamLibre = typeof ramLibre === "number" && ramLibre > 2 && pct > 50;
           results.push({
             id:"swap_usage", label:"Uso de SWAP",
-            status: pct > 95 ? "warn" : "ok",
+            status: pct > 80 ? "error" : pct > 50 ? "warn" : "ok",
-            detail: pct > 95
+            detail: pct > 50
-              ? `SWAP al ${pct}%. Fulcrum está usando casi toda la memoria de intercambio. Normal en nodos con índice completo, pero monitoriza que el OOM Killer no actúe.`
+              ? `SWAP al ${pct}% (${swapStats.used_gb || "?"} GB).${conRamLibre ? ` Y eso ocurriendo con ${ramLibre} GB de RAM libre, que es la señal típica de un servicio con más memoria reservada de la que cabe en la máquina.` : ""} Con el swap lleno el sistema se queda sin margen: ante un pico de memoria actúa el OOM killer, y elige él qué proceso mata — puede tocarle a bitcoind o a Fulcrum en mitad de una escritura. El sospechoso habitual es \`db_mem\` en la configuración de Fulcrum: acelera la sincronización inicial y mucha gente lo sube para eso y no lo vuelve a bajar. Para ver quién ocupa el swap: for p in /proc/[0-9]*; do s=$(awk '/VmSwap/{print $2}' $p/status 2>/dev/null); [ -n "$s" ] && [ "$s" -gt 0 ] && echo "$s KB $(cat $p/comm)"; done | sort -rn | head`
-              : `SWAP al ${pct}%. Uso normal.`,
+              : `SWAP al ${pct}%. Sin presión de memoria.`,
           });
         }
 
@@ -6714,7 +6731,7 @@
             <H>Sistema</H>
             <Li><strong style={{color:C.t1}}>CPU por núcleo</strong> — uso individual de cada núcleo. Calculado desde <Code>/proc/stat</Code>, equivalente a htop.</Li>
             <Li><strong style={{color:C.t1}}>RAM</strong> — memoria realmente usada por procesos, excluyendo caché del kernel (mismo cálculo que htop).</Li>
-            <Li><strong style={{color:C.t1}}>SWAP</strong> — memoria de intercambio en uso. Un valor alto sostenido (como el de Fulcrum) es normal pero conviene monitorizarlo.</Li>
+            <Li><strong style={{color:C.t1}}>SWAP</strong> — memoria de intercambio en uso. Debería estar cerca de cero. Un valor alto <em>no</em> es normal aunque se repita: significa que algún servicio tiene reservada más memoria de la que cabe en la máquina, y deja al sistema sin margen ante un pico. Si sube teniendo RAM libre, el sospechoso habitual es <Code>db_mem</Code> en la configuración de Fulcrum — se sube para acelerar la sincronización inicial y es fácil olvidarse de bajarlo.</Li>
             <Li><strong style={{color:C.t1}}>Procesos destacados</strong> — los procesos que más memoria consumen en tiempo real.</Li>
             <H>Logs en tiempo real</H>
             <P>Panel de logs de Bitcoin Core y Fulcrum. Muestra las últimas 80 entradas con filtrado por nivel (todos / warn / error). Pulsa ↻ para actualizar.</P>