fix: dos fallos en la detección del output de cambio

Uno: la señal A y la señal E eran la misma condición escrita dos veces, así que
un solo hecho llegaba al umbral de dos señales. Un pago corriente de bech32 a
taproot salía como cambio identificable con certeza PROBABLE, y el informe
mostraba las dos señales contradiciéndose entre sí.

Dos: sin señal fuerte, el índice caía en la salida menor. Pagando poco desde
una moneda grande el cambio es la mayor, así que la app señalaba el pago. El
detalle llegaba a decir 'el output redondo es el pago' y a continuación lo
marcaba como cambio. El peritaje usa ese índice, de modo que podía presentar
la dirección del destinatario como rastro del actor.

Ahora cada señal apunta a un output o admite que no puede, y si ninguna apunta
el índice queda vacío. tests/test5.js deja los dos casos como regresión.

CHANGELOG.md

@@ -10,6 +10,46 @@ y el versionado sigue [Versionado Semántico](https://semver.org/lang/es/):
 - **MENOR** — características nuevas que no rompen lo anterior
 - **PARCHE** — arreglos de errores
 
+---
+## [1.15.0] — 2026-08-08
+### Corregido
+- **La detección del cambio contaba una misma señal dos veces.** La "señal A"
+  (solo una salida comparte tipo de script con las entradas) y la "señal E"
+  (el tipo de output difiere del de las entradas) eran la misma condición
+  escrita dos veces —el mismo `filter`, la misma comparación, el mismo `=== 1`—
+  y cada una incrementaba el contador. Como el umbral para declarar el cambio
+  identificable es de dos señales, **ese único hecho bastaba por sí solo**.
+  - Consecuencia práctica: pagar desde una dirección bech32 a una taproot —de
+    lo más común que hay— salía marcado como "cambio identificable" con certeza
+    PROBABLE, sin ninguna otra evidencia.
+  - Y el informe mostraba las dos señales juntas, que se contradicen entre sí:
+    "tipo de script idéntico a inputs" y "tipo de output distinto al de inputs".
+    El mismo hecho descrito con palabras opuestas.
+  - Ahora es una sola señal. Esa transacción pasa a una señal y a **no
+    identificable**, que es lo correcto. Cuando queda una sola señal el check
+    lo dice en vez de callarse: existe, no basta, y conviene que se sepa que
+    otro analista menos escrupuloso la daría por buena ella sola.
+- **Se podía señalar el pago como si fuera el cambio.** Cuando ninguna señal
+  fuerte apuntaba a un output concreto, el índice caía en `indexOf(smaller)`:
+  se asumía que el cambio es siempre la salida menor. Es falso en el caso más
+  común de todos —pagar poco desde una moneda grande—, donde el cambio es la
+  salida *mayor*.
+  - Comprobado con un pago de 0,001 BTC desde 1 BTC: la app decía en el detalle
+    "el output redondo es el pago" y acto seguido señalaba ese mismo output
+    como cambio. La información para acertar estaba delante y se descartaba.
+  - Esto no se quedaba en el analizador: el motor de peritaje usa ese índice
+    para detectar cadenas de peeling y para redactar el informe. Un cambio mal
+    identificado significa presentar como rastro del actor **la dirección del
+    destinatario del pago**, una persona ajena.
+  - Ahora cada señal apunta a un output o reconoce que no puede. El orden de
+    resolución es: reutilización de dirección de entrada → tipo de script →
+    la salida NO redonda → posición. Si ninguna apunta, el índice queda vacío
+    y se dice que hay señales pero no cuál — preferible a señalar mal.
+
+### Añadido
+- `tests/test5.js` — seis casos de detección de cambio con el pago y el cambio
+  conocidos de antemano, incluidos los dos fallos anteriores como regresión.
+
 ---
 ## [1.14.0] — 2026-08-08
 ### Añadido