docs: documentar los límites reales del peritaje y afinar el aviso de consulta fallida

- el aviso ya no promete que el fallo es transitorio: cuando se repite sobre
  la misma dirección no lo es, y ahora dice por qué y qué hacer
- README: las ramas no comprobadas quedan fuera de 'fondos sin gastar' a
  propósito — cortar protege el nodo y una consulta fallida no es una
  conclusión
- README: el tope de volumen mide número de tx, no peso; una dirección con
  pocas transacciones muy grandes puede agotar el tiempo de espera igual
  (visto con una de 59 tx de ~15 KB)

CHANGELOG.md

@@ -38,6 +38,18 @@ y el versionado sigue [Versionado Semántico](https://semver.org/lang/es/):
 - Peritaje: el botón "Generar informe" explica por qué está deshabilitado en
   vez de quedarse inerte sin dar motivo.
 
+### Cambiado
+- El aviso de consulta fallida ya no dice que el fallo "suele ser transitorio":
+  cuando se repite sobre la misma dirección no lo es, y ahora lo explica —
+  historial demasiado pesado para servirlo dentro del tiempo de espera, con la
+  indicación de comprobarla a mano antes de dar el rastro por cerrado.
+
+### Documentación
+- README: documentadas dos limitaciones reales del peritaje — las ramas que no
+  se pueden comprobar (y por qué cortar es deliberado, no un defecto), y que el
+  tope de volumen mide número de transacciones y no peso, así que una dirección
+  con pocas transacciones muy grandes puede agotar el tiempo de espera igual.
+
 ---
 ## [1.10.0] — 2026-07-16
 ### Añadido

README.md

@@ -203,7 +203,9 @@ El frontend es un único archivo HTML autocontenido. Sin bundler, sin npm, sin p
 - **Base de datos de entidades parcial** — ~745 direcciones de exchanges, OFAC y minería. Cubre los casos más comunes; no es completa
 - **Fingerprinting conservador** — requiere varias señales coincidentes; prefiere no detectar antes que detectar mal
 - **Sin análisis de red** — no cruza datos con otros nodos ni mempool distribuida
-- **Peritaje forense sin `/outspend`** — el backend Mempool self-hosted no expone ese endpoint, así que cada salto se resuelve recorriendo el historial de la dirección receptora. Más peticiones que un `/outspend` directo, con throttling por lotes para no saturar el nodo
+- **Peritaje forense sin `/outspend`** — el backend Mempool self-hosted no expone ese endpoint (ni `/utxo`), así que cada salto se resuelve recorriendo el historial de la dirección receptora. Más peticiones que un `/outspend` directo, con throttling por lotes para no saturar el nodo
+- **Ramas que no se pueden comprobar** — algunas direcciones tienen un historial tan pesado que el backend no lo sirve dentro del tiempo de espera (8 s). Cuando pasa, esa rama se marca como **no comprobada** y queda fuera de "fondos localizados sin gastar": el informe dice que no se sabe, en vez de afirmar que los fondos siguen ahí. Es deliberado — cortar protege el nodo, que es la premisa de la herramienta, y una consulta fallida nunca debe leerse como una conclusión. Esas ramas hay que comprobarlas a mano
+- **El tope de volumen mide número de transacciones, no peso** — el cinturón de seguridad (`LARGE_ADDR_TX_COUNT`, 5000 tx) frena las direcciones con historiales enormes, pero una dirección con pocas transacciones muy grandes puede agotar el tiempo de espera igualmente (visto con una de 59 transacciones de ~15 KB cada una). No hay forma barata de conocer el peso de la respuesta por adelantado, así que el tope no cubre ese caso; lo cubre el manejo de errores descrito arriba
 
 ---
 

dashboard.html

@@ -4256,7 +4256,7 @@
       // se pudo consultar, el lector debe saberlo antes de leer nada más.
       if (failedBranches.length > 0) {
         conclusions.push({ level:"HECHO",
-          text:`ATENCIÓN — rastreo incompleto por fallos de consulta: ${failedBranches.length} rama(s) quedaron sin comprobar porque el nodo no respondió (${[...new Set(failedBranches.map(f=>f.address))].join(", ")}). NO se sabe si esos fondos siguen sin gastar o se movieron: la consulta falló, no se comprobó nada. Repite el rastreo sobre esas ramas antes de dar por bueno el alcance de este informe.`,
+          text:`ATENCIÓN — rastreo incompleto por fallos de consulta: ${failedBranches.length} rama(s) quedaron sin comprobar porque el nodo no respondió (${[...new Set(failedBranches.map(f=>f.address))].join(", ")}). NO se sabe si esos fondos siguen sin gastar o se movieron: la consulta falló, no se comprobó nada. Si el fallo se repite sobre la misma dirección, suele ser porque su historial es demasiado pesado para servirlo dentro del tiempo de espera — hay que comprobarla a mano en un explorador. Este informe no cubre esas ramas.`,
           refs: failedBranches.map(f=>f.txid) });
       }
       if (queryErrors.some(q => q.context === "perfil de dirección")) {
@@ -5277,7 +5277,7 @@
                     ⚠ Rastro incompleto — {trace.queryErrors.length} consulta(s) al nodo fallaron
                   </div>
                   <div style={{fontSize:"0.62rem",color:C.t1,fontFamily:"monospace",lineHeight:1.6}}>
-                    No quedan ramas por explorar, pero algunas no se pudieron comprobar: no se sabe si esos fondos siguen sin gastar o se movieron. Suele ser transitorio (nodo ocupado o dirección con mucho historial) — pulsa "Limpiar" y repite el rastreo.
+                    No quedan ramas por explorar, pero algunas no se pudieron comprobar: no se sabe si esos fondos siguen sin gastar o se movieron. Si el nodo estaba ocupado, repetir el rastreo ("Limpiar") suele bastar. Si vuelve a fallar en la misma dirección, no es casualidad: esa dirección tiene un historial demasiado pesado para servirlo dentro del tiempo de espera, y el corte es la protección del nodo haciendo su trabajo. Compruébala a mano en el explorador antes de dar el rastro por cerrado.
                   </div>
                   <div style={{marginTop:6,display:"flex",flexDirection:"column",gap:2}}>
                     {trace.queryErrors.slice(0,5).map((q,i)=>(