fix: endurecer la validación del xpub tras revisar la criptografía

La matemática pasa todos los vectores oficiales (RIPEMD-160, secp256k1, BIP32
vectores 1 y 2, bech32/BIP173) y no se ha tocado. Los fallos estaban en la
validación de la entrada:

- No se comprobaba la checksum del xpub: un carácter mal copiado generaba 200
  direcciones ajenas y el usuario veía su cartera 'sin actividad'. Mismo
  patrón de falso negativo silencioso que el resto de fallos de hoy.
- No se validaba la longitud (78 bytes) ni el formato de la clave pública.
- tpub se trataba como mainnet: la red se detectaba por prefijo de texto
  ('tb'/'u'/'v') y un tpub empieza por 't' pero no por 'tb'. Ahora se detecta
  por bytes de versión, con las diez variantes.
- deriveChildPubkey aceptaba índices endurecidos, imposibles desde una clave
  pública. No alcanzable desde la UI, pero debe defenderse sola.

Se añade tests/ con las cuatro baterías, documentando también qué NO cubren:
no sustituyen una auditoría externa.

tests/README.md

@@ -0,0 +1,47 @@
+# Pruebas de la criptografía
+
+Verifican la derivación watch-only (BIP32, secp256k1, RIPEMD-160, bech32)
+contra los **vectores oficiales de los estándares**, no contra resultados
+propios. Si un cambio rompe algo, estas pruebas lo dicen.
+
+## Cómo ejecutarlas
+
+Extraer el bloque criptográfico de `dashboard.html` a `crypto.js` (las líneas
+que van desde `const B32 = {` hasta el final de `deriveAddresses`), añadir al
+principio `const { webcrypto } = require("crypto"); const crypto = webcrypto;`
+y al final la exportación:
+
+    module.exports = { B32, SECP, deriveChildPubkey, ripemd160, hash160, toBech32, deriveAddresses };
+
+Después:
+
+    node test1.js   # RIPEMD-160 y aritmética de curva
+    node test2.js   # BIP32 y bech32 contra vectores oficiales
+    node test3.js   # búsqueda de casos borde (diagnóstico)
+    node test4.js   # regresión de los fallos ya corregidos
+
+## Qué cubren
+
+- **test1** — RIPEMD-160 con los seis vectores del estándar (incluido el de un
+  millón de caracteres), generador de secp256k1, múltiplos conocidos, y que
+  comprimir y descomprimir un punto sea reversible.
+- **test2** — BIP32: clave pública y chain code de la raíz, y derivación no
+  endurecida `m/0`, contra los vectores 1 y 2 del propio BIP32. bech32: la
+  dirección P2WPKH del generador, en mainnet y testnet (BIP173).
+- **test3** — sondeo de casos borde. Fue el que encontró los cuatro fallos de
+  validación corregidos el 2026-07-27.
+- **test4** — comprueba que esos cuatro siguen cerrados: checksum rota, xpub
+  truncado, índice endurecido, índice negativo. Y que un `tpub` genera
+  direcciones de testnet, no de mainnet.
+
+## Lo que estas pruebas NO cubren
+
+La matemática es correcta, pero eso no es una auditoría. No cubren análisis
+formal ni una revisión independiente: quien las escribió conoce la
+implementación y comparte sus supuestos, que es justo el sesgo que rompe un
+revisor externo. Siguen haciendo falta ojos de fuera antes de difundir el
+proyecto ampliamente.
+
+Tampoco aplican aquí los ataques de canal lateral: todo esto maneja **solo
+claves públicas**. No hay secreto que filtrar; lo único que importa es que el
+resultado sea correcto, y eso es lo que se comprueba.