feat: tope de ramificación en el peritaje — no seguir repartos masivos

Una tx con cientos de salidas (dust attack, lote de retiradas, airdrop) hacía
que el motor perfilara cada dirección de salida (2 peticiones cada una) antes
de encolar las ramas: ~286 peticiones para una tx de 143 salidas, con la
pestaña congelada. El tope corta antes de perfilar, que es donde está el coste.

Verificado contra el nodo con una tx real de 143 salidas: 2 peticiones.

CHANGELOG.md

@@ -12,6 +12,19 @@ y el versionado sigue [Versionado Semántico](https://semver.org/lang/es/):
 
 ---
 ## [1.10.1] — 2026-07-27
+### Añadido
+- **Tope de ramificación en el peritaje (`MAX_FANOUT`, 25 salidas).** Detectado
+  probando el fixture de dust attack: una transacción que reparte a cientos de
+  direcciones hacía que el motor encolara todas sus ramas y, sobre todo, que
+  perfilara cada dirección de salida — 2 peticiones por dirección, así que una
+  tx de 143 salidas suponía ~286 peticiones al nodo antes siquiera de llegar al
+  frontier, y la pestaña se congelaba. Ahora, por encima del tope, la tx se
+  trata como reparto masivo (dust attack, lote de retiradas, airdrop): se corta
+  ANTES de perfilar nada, con `stopReason: "fanOut"` y su propia conclusión en
+  el informe, redactada como límite deliberado y no como inferencia sobre quién
+  controla esas direcciones. Verificado con una tx real de 143 salidas: 2
+  peticiones en total.
+
 ### Corregido
 - **Peritaje forense: un fallo de consulta ya no se presenta como "rastro
   completo".** Detectado probando contra el nodo real: cuando el backend