use SecureRandom for digest auth cnonce

[jmestwa-coder]

The digest cnonce was drawn from a non-cryptographic PRNG:

• Realm.Builder.newCnonce seeds the cnonce from ThreadLocalRandom, whose output is predictable
• RFC 7616 section 3.3 needs the cnonce unpredictable so it guards against chosen-plaintext and precomputation attacks on the credentials
• NtlmEngine and ScramEngine in this repo already use SecureRandom for their nonces

Switched the cnonce source to SecureRandom to match.

[hyperxpro]

Don't share one static SecureRandom; use a ThreadLocal. newCnonce runs on Netty event-loop threads (digest header build + 401/407 interceptors), and SecureRandom#nextBytes locks internally, so a single shared instance makes all event loops queue on one lock. ThreadLocalRandom had no such lock. ScramEngine already handles this the right way:

private static final ThreadLocal<SecureRandom> CNONCE_RANDOM = ThreadLocal.withInitial(SecureRandom::new);

and in newCnonce:

CNONCE_RANDOM.get().nextBytes(b);

[jmestwa-coder]

good catch. switched to ThreadLocal.withInitial(SecureRandom::new) to match ScramEngine so the event loops don't serialize on one lock.

[hyperxpro]

the md.digest(b) step is now pointless. The 8 bytes are already cryptographically random, so hashing them and trimming back to 8 bytes adds nothing. The method can just be:

private void newCnonce() {
    byte[] b = new byte[8];
    CNONCE_RANDOM.get().nextBytes(b);
    cnonce = toHexString(b);
}

Same 16-hex-char cnonce. This is safe because pooledMessageDigest already resets the digest before build() gets it, so nothing downstream depends on the digest(b) call.

[jmestwa-coder]

makes sense. dropped the digest step, newCnonce now hex-encodes the 8 random bytes directly, and removed the now-unused Arrays import. same 16-hex cnonce and the digest handed to newResponse is still the reset pooled instance.