Generador de número aleatorio

No es `Math.random()`. Cada tirada llama a `crypto.getRandomValues()` de la W3C Web Cryptography API (Recomendación de 26 de enero de 2017), que toma bytes del pool de entropía del sistema operativo (Linux `/dev/urandom`, framework Security de macOS, `BCryptGenRandom` en Windows) — la misma fuente que los gestores de contraseñas modernos y los handshakes TLS. `Math.random()` es rápido pero V8 (Chrome, Node, Edge) y SpiderMonkey (Firefox) lo implementan con el algoritmo xorshift128+ (Vigna 2014; V8 lo adoptó en v4.9.41 con Chrome 49 estable en marzo de 2016, sustituyendo a MWC1616) — pasa la batería estadística BigCrush pero no es criptográficamente seguro y sería la primitiva equivocada para una herramienta que entrega números de lotería, sorteos o tokens de sesión.

El sesgo de módulo es la pequeña pero sistemática desviación que aparece al tomar un entero de un rango uniforme y reducirlo mod N cuando N no divide al rango fuente de forma exacta. La fuente subyacente aquí es un entero de 32 bits sin signo (rango 0..2³²−1). Si pides un número en 1..100, el ingenuo `r % 100` da a cada valor de 0..95 una probabilidad de 42.949.673 mapeos sobre 2³² y a cada valor de 96..99 solo 42.949.672 mapeos — los números bajos son ligeramente más probables. El exceso por valor bajo es de 1/2³² ≈ 1 entre 4.300 millones, invisible para un lanzamiento de moneda pero acumulativo en millones de tiradas (loterías reguladas, emisión de tokens de seguridad). La solución es rejection sampling: tira, comprueba si el valor cae dentro del múltiplo mayor de N que cabe, reintenta si no. El `randInt(n)` de esta herramienta hace exactamente eso — el número esperado de reintentos está acotado por 2 sea cual sea N, así que el coste es despreciable.

El reintento sobre duplicados (el enfoque obvio) se vuelve patológicamente lento cuando el número de tiradas se acerca al tamaño del rango — extraer las últimas unidades únicas de 1..100 requiere de media unas 519 tiradas para conseguir los 100 distintos (el límite del coleccionista de cupones, n · H_n ≈ 100 × 5,187) y sesga las últimas porque los duplicados desplazan la distribución empírica. Fisher-Yates (Algoritmo P de Knuth en Art of Computer Programming Vol 2 §3.4.2 de 1969, adaptación in-place de Durstenfeld CACM 1964 del procedimiento original de Fisher y Yates 1938 con lápiz y papel) genera una permutación uniformemente aleatoria del pool entero en tiempo O(rango) y espacio O(rango), y luego toma los primeros N elementos. Toda permutación es igualmente probable, todo conjunto solo-único es igualmente probable, y el tiempo de ejecución se mantiene lineal en el tamaño del rango sin importar cuántos se extraigan.

Para usos de bajo riesgo (rifa de oficina, asignación de asientos en clase, cubeta de test A/B, elegir un ganador de un hilo de comentarios) la fuente `crypto.getRandomValues()` de esta herramienta basta y sobra — es la misma primitiva que la RFC 4086 (Eastlake/Schiller/Crocker BCP 106 de junio de 2005) recomienda para generación de claves criptográficas no adversariales. Para loterías reguladas (juegos con licencia estatal, muestreo aleatorio de valores, aleatorización de ensayos clínicos) la regla es procedimental, no estadística: los reguladores exigen pista de auditoría (semillas registradas, sorteos atestiguados, cadenas hash de terceros) y un RNG hardware con pruebas estadísticas periódicas (NIST SP 800-22, validación de módulo FIPS 140), ninguno de los cuales una herramienta del lado del cliente puede proporcionar. Conviene reservarla para tiradas cotidianas; para algo legalmente vinculante toca un servicio regulado auditado o un sorteo físico notarizado.

Esta herramienta genera enteros — eso es lo que produce `randInt(maxExclusive)` desde `crypto.getRandomValues()` con rejection sampling. El tope interno son 2³² porque el buffer de entropía subyacente es un Uint32Array; los rangos hasta unos 4.290 millones funcionan de forma nativa, más allá haría falta una tirada multipalabra que esta herramienta no expone. Para números aleatorios en coma flotante en [0, 1) la función auxiliar `rand()` de `src/lib/random.ts` divide un Uint32 por 2³², dando 32 bits de precisión fraccional — suficiente para la mayoría de simulaciones pero no los 53 bits totales de un double de JavaScript (la solución es `crypto.getRandomValues()` con un `BigUint64Array` para doubles de 64 bits). Los rangos negativos, los `min/max` invertidos y las cantidades mayores que el rango entero se gestionan intercambiando extremos y recortando la cantidad automáticamente.