Hybrid post-quantum Noise handshake (X25519 + ML-KEM-768)

Nobody has claimed this yet.

### Why
`/noise` is classical X25519, so recorded sessions are open to harvest-now-decrypt-later. A hybrid KEM closes that, and stays secure if either primitive holds.

### Proposal
A new, separately negotiated handshake (not a change to `/noise`), keeping the spec's "one id, one fixed suite" design:

- id: `/noise-mlkem768-hfs/0.1.0` (provisional)
- suite: `Noise_XXhfs_25519+ML-KEM-768_ChaChaPoly_SHA256`. XX with [Hybrid Forward Secrecy](https://github.com/noiseprotocol/noise_wiki/wiki/Hybrid-Forward-Secrecy); ML-KEM-768 (FIPS 203) mixed into the chain alongside the X25519 DHs.

Identity payload and signature are unchanged. Authentication stays classical (it cannot be broken retroactively); only confidentiality is HNDL-sensitive.

Implementations advertise the hybrid id ahead of `/noise`, so a mixed fleet falls back with no flag day.

### Reference impl
Working in Rust: libp2p/rust-libp2p#6481 over mcginty/snow#210. Revives #2168.

### To pin for interop
1. Protocol id string.
2. Exact HFS token placement and KDF mixing order, with KATs, so go/js/rust agree byte for byte.
3. ML-KEM-768 only, or the 512/768/1024 family?

Start with the existing /noise handshake specification and the referenced rust-libp2p#6481 and snow#210 implementations. Review the open interop decisions around the protocol id, HFS token placement, KDF mixing order, KATs, and ML-KEM parameter scope; done means those choices are pinned for byte-for-byte agreement across implementations.

Written by the indexing model from the issue text.