net.quic: use crypto.rand instead of rand for connection IDs and TLS random

[quaesitor-scientiam]

Summary

• dial() in vlib/net/quic/conn.v generated original_dcid, scid, and the TLS 1.3 ClientHello.random using the plain rand module, which defaults to WyRandRNG — a fast, explicitly non-cryptographic PRNG (vlib/rand/rand.v).
• RFC 9000 §8.1 expects connection IDs to carry real entropy (e.g. "contains at least 64 bits of entropy"), and ClientHello.random has its own TLS 1.3 security properties — neither is satisfied by a non-cryptographic PRNG.
• Swapped to crypto.rand, this repo's existing OS-backed CSPRNG (getrandom on Linux, platform equivalents on Windows/BSD/Solaris/macOS), which already exposes an identical pub fn bytes(bytes_needed int) ![]u8 signature and is already used elsewhere in the codebase (e.g. crypto.ecdsa). This is a drop-in swap — no call-site changes needed.
• This is part of the already-merged HTTP/3 client (HTTP/3 (QUIC) foundation: Phase 12 (HTTP/3 client wiring) #28129, Phase 9), so it's a real gap in shipped code, not WIP.

Checked for the same pattern elsewhere: vlib/net/http/request.v also imports plain rand, but only for rand.ulid() on a multipart form boundary — not security-relevant (needs uniqueness, not unpredictability), and out of scope for this fix.

Test plan

• Built ./vnew fresh and ran ./vnew -silent test vlib/net/quic/ — 54/54 passed, both before and after the change (confirmed via git stash that the interspersed "v3 compiler memory usage" messages are pre-existing noise from an unrelated experimental v3 compiler bench, unaffected by this change)
• ./vnew fmt -w vlib/net/quic/conn.v — already clean
• Confirmed no test in vlib/net/quic/ seeds rand globally or depends on dial()'s specific randomness for determinism
• Confirmed no other file imports quic's re-exported rand

🤖 Generated with Claude Code