fix: generate the search token with a CSPRNG

[snowyukitty]

Description

Fixes #2181.

server/searchToken.ts mints the shared secret behind every /search/* and /inference request — the client hashes it with argon2id as VITE_SEARCH_TOKEN, and verifyTokenAndRateLimit authorizes by verifying that hash against getSearchToken(). It was generated with Math.random().toString(36).substring(2), so the secret came from a non-cryptographic PRNG and carried at most the 52 bits a double's mantissa can hold. The encoded string is also variable length — 7 to 15 characters over 2M samples on Node 22, not the ~11 it looks like.

Now it's 32 bytes from node:crypto, hex-encoded. The client already reaches for the CSPRNG (crypto.getRandomValues in accessKey.ts and searchTokenHash.ts), so this brings the server side in line.

docs/security.md called out the weak source under "Security Best Practices", so that line is updated in the same commit.

Scope note: this changes the quality of the secret, not its lifetime — regenerateSearchToken() still only runs on build, and getSearchToken() still returns the cached temp-file value.

The other Math.random() call sites (history.ts, logEntries.ts, querySuggestions.ts, wllama.ts, shared/openaiModels.ts, and the backoff jitter in server/utils/streamUtils.ts) are all non-security and left alone.

The new test pins the invariant rather than the implementation: it spies on Math.random, asserts it is never reached, and checks two successive tokens differ. On the previous implementation it fails with expected "random" to not be called at all, but actually been called 2 times.

Type of Change

• Bug fix
• New feature
• Documentation
• Other (refactor, build, chore)

Checklist

• npm run lint passes
• Tests pass (npm run test), with tests added where it made sense

Security, performance, or breaking changes? Expand if relevant.

Security-positive, no migration needed. The token moves from ≤52 bits of Math.random() output to 256 bits of CSPRNG output, and from a 7–15 character base-36 string to a fixed 64-character hex string. Existing deployments pick up the new token on their next build, exactly as they already do today — the temp file is rewritten by regenerateSearchToken() and re-inlined as VITE_SEARCH_TOKEN. argon2id takes the longer password unchanged (verified with a real hash-wasm round trip using the client's exact parameters).

[felladrin]

Excellent! Thanks for another contribution!