Russh: Missing X25519 zero-point validation in hybrid ML-KEM key exchange

## Vulnerability The hybrid ML-KEM 768 + X25519 key exchange implementation in `russh/src/kex/hybrid_mlkem.rs` does not validate that the remote peer's X25519 public key is not the zero point (all-zero 32-byte value). This allows a remote peer to force the X25519 contribution to the combined shared secret to zero, reducing the hybrid KEX to a single-algorithm exchange. Affected code at HEAD (v0.62.4, commit 0089c89): **Server-side** (`server_dh`, lines 92-93): ```rust let mut c_pk1 = MontgomeryPoint([0; 32]); c_pk1.0.copy_from_slice(c_pk1_bytes); // No zero-point check - proceeds to: let k_cl = s_secret * c_pk1; ``` **Client-side** (`compute_shared_secret`, lines 154-155): ```rust let mut s_pk1 = MontgomeryPoint([0; 32]); s_pk1.0.copy_from_slice(s_pk1_bytes); // No zero-point check - proceeds to: let k_cl = x25519_secret * s_pk1; ``` ## Root Cause Commit a7fc1eb (2026-07-22, "fix mpint encoding and validate curve25519 keys") added zero-point validation to the standalone Curve25519 KEX in `russh/src/kex/curve25519.rs` at two locations: - `server_dh` line 77: `if client_pubkey.0 == [0u8; 32] { return Err(crate::Error::Kex); }` - `compute_shared_secret` line 122: `if remote_pubkey.0 == [0u8; 32] { return Err(crate::Error::Kex); }` The same X25519 scalar multiplication pattern appears in `hybrid_mlkem.rs`, but the fix was not applied there. ## Proof of Concept A malicious SSH client negotiating `mlkem768x25519-sha256` can send a KEX_HYBRID_INIT message containing a valid ML-KEM 7