Expose ML-KEM hybrid key exchange (X25519MLKEM768) as a rustls kx group

rustls-symcrypt currently exposes SECP256R1, SECP384R1, and X25519 (feature-gated) as key exchange groups. There is no PQ hybrid group, so servers using this provider cannot negotiate X25519MLKEM768.

My understanding is that SymCrypt itself already has this. I checked the CHANGELOG and it includes an ML-KEM implementation per final FIPS 203, pairwise consistency tests for ML-KEM key generation, and Rust implementations ("Added Rust implementations of ML-KEM and SHA3"). However, exposing it as a rustls SupportedKxGroup has not happened yet.

Context: rustls's aws-lc-rs provider ships X25519MLKEM768, and Chrome, Go 1.24+, and OpenSSL 3.5+ clients offer it by default. So choosing rustls-symcrypt currently means giving up PQ key exchange. As a real downstream case, I ran into agentgateway's crypto-symcrypt backend building without PQ because of this constraint (agentgateway/agentgateway#3130, with measured data).

Request: please expose X25519MLKEM768 (and ideally standalone MLKEM768) as a SupportedKxGroup. Happy to help with testing.

Start by tracing the existing SECP256R1, SECP384R1, and X25519 key exchange implementations to the rustls SupportedKxGroup entry points. Check the CHANGELOG and SymCrypt's ML-KEM support before determining how X25519MLKEM768, and optionally standalone MLKEM768, fit the provider. Done means the provider exposes the requested group and servers can negotiate it with compatible clients.