ci: tests en las tres plataformas antes de desplegar, y una sola fuente para la version y para SHA-256

[Oloxx]

Las cuatro issues P2 que se sostienen entre ellas: la suite no podía correr en CI,
CI no existía, la versión vivía en dos sitios y el test de SHA-256 validaba una copia.

La suite arranca su propio servidor (#23)

npm test daba por hecho un servidor escuchando en el 3000. En un clon limpio fallaba
con errores de conexión que no explican nada, y en un runner no hay tal servidor: por eso
release.yml lo levantaba a mano con un curl en bucle antes de los tests.

test/helpers.mjs lo arranca en un puerto efímero y lo apaga al acabar. Ahí viven también
el ayudante de WebSocket y freePort, que estaban copiados en tres ficheros.

Cada fichero de tests sigue teniendo el suyo a propósito: las cuotas por IP son del
proceso y el caso de fuerza bruta deja 127.0.0.1 limitado durante un minuto.
DROP_URL se mantiene para apuntar a un servidor externo.

Tests antes de desplegar (#22)

deploy.yml era el único workflow que corría en un push a main, y desplegaba sin
ejecutar nada. El VPS hace git reset --hard origin/main, así que un commit que rompiera
el servidor de señalización llegaba a producción y solo se notaba al usarlo.

• ci.yml: npm test en Linux, macOS y Windows. Las tres plataformas donde se publica un
  binario, y las tres que se comportan distinto abriendo puertos y lanzando procesos.
• deploy.yml lo llama como workflow reutilizable y depende de él.
• En un push a main corre una sola vez: ci.yml se activa por su cuenta únicamente en
  las rutas que no despliegan nada (cli/, test/, scripts/).
• El dominio del healthcheck sale de la variable de repositorio DROP_PUBLIC_URL (ya
  creada). Sin ella se comprueba por dentro del contenedor, como hasta ahora.

La versión, en un solo sitio (#26)

Estaba a mano en const VERSION de cli/src/cli.js y en el package.json. No es
cosmético: drop update compara la release de GitHub contra esa constante, así que una
constante vieja deja al CLI creyéndose desactualizado para siempre —reinstalando en
bucle— o sin enterarse nunca de una versión nueva.

Ahora sale del package.json: cli.js lo importa como JSON y esbuild mete el fichero
dentro del bundle al empaquetar, así que el binario no lee nada en marcha.

test/version.test.mjs cae si vuelve a aparecer un literal, si drop --version no
coincide con el package.json, o si los enlaces de descarga del README apuntan a otra
versión —lo que se quedaba atrás al sacar una release con prisa—. Las menciones en prosa
("a partir de la v0.5.2") hablan de una versión concreta y no se tocan.

En release.yml queda solo la comprobación del tag.

Una sola implementación de SHA-256 (#25)

test/integrity.test.mjs copiaba las doscientas líneas de public/app.js: validaba su
copia, no el original. Pasan a public/shared/sha256.js y las dos partes lo importan.
Sigue siendo implementación propia porque hace falta hashear incrementalmente según llegan
los trozos, y crypto.subtle.digest es de un solo golpe.

Verificación

• npm test en un árbol limpio, sin levantar nada: 104/104.
• npm run build:exe y el ejecutable ya inyectado responde drop v0.5.2 — la inyección de
  la versión está probada sobre el binario real, no solo sobre el fuente.
• Transferencia real por navegador con Chrome (throughput.bench.mjs, 8 MB): el receptor
  comprueba el hash del archivo con el módulo compartido y lo da por bueno.
• Las tres plataformas de la matriz se verán por primera vez en este mismo PR.

Closes #23, closes #22, closes #26, closes #25.