crypto: support derandomized ML-KEM encapsulation

[dotCooCoo]

Summary

Adds an entropy option to crypto.encapsulate() for derandomized (deterministic)
ML-KEM encapsulation, mapping to OpenSSL 3.5's OSSL_KEM_PARAM_IKME (FIPS 203 §6.2
Encaps_internal). The same entropy + public key + algorithm deterministically produce
the same ciphertext and sharedKey — needed for known-answer testing and for hybrid
KEMs such as X-Wing (draft-connolly-cfrg-xwing-kem), which are defined in terms of
ML-KEM's internal encapsulation.

The existing randomized encapsulate(key) / encapsulate(key, callback) forms are
unchanged; the new shape is encapsulate(key, { entropy }). The 32-byte buffer is threaded
through KEMEncapsulateJob → ncrypto::KEM::Encapsulate and set on the EVP_PKEY_CTX
before EVP_PKEY_encapsulate, gated on OpenSSL >= 3.5 (OPENSSL_WITH_KEM_IKME). The binding
enforces an exactly-32-byte length and is ML-KEM-only; the randomized path is byte-identical
to today (an absent/undefined entropy takes the existing CSPRNG path).

Docs and tests are included (determinism, decapsulate round-trip, both length bounds,
empty/undefined handling, and type rejection). Built and tested locally on Windows with
OpenSSL 3.5.7; test/parallel/test-crypto-encap-decap.js passes.

Fixes: #64206

[nodejs-github-bot]

Review requested:

• @nodejs/crypto
• @nodejs/security-wg

[panva]

https://docs.openssl.org/3.6/man7/EVP_KEM-ML-KEM/#ml-kem-kem-parameters
This parameter should not be used for purposes other than testing.

https://www.ietf.org/archive/id/draft-connolly-cfrg-xwing-kem-10.html#name-derandomized
For testing, it is convenient to have a deterministic version of encapsulation. An X-Wing implementation MAY provide the following derandomized function.

This is distinctly only for test vector validation, as such I don't think it's worth the churn in node:crypto. Hybrid KEMs do not make use of it other than vector testing either.

[dotCooCoo]

That's a fair point @panva. I wasn't thinking of this as a production feature so much as exposing a testing primitive that OpenSSL already provides.

The main use case I had in mind was deterministic vector validation and interoperability/regression testing. Today that requires dropping down to OpenSSL or another implementation, even though the underlying capability already exists.

[panva]

I don't think we should be adding an option which we'd need to document effectively as "this is a footgun, don't use it".