[kem] Reject invalid hybrid key lengths without panicking

[bshastry]

Summary

• reject non-exact hybrid private and public key encodings before splitting their ML-KEM and X25519 components
• replace hard-coded split offsets with the key types' length constants
• add malformed-length regression tests and valid-key round-trip tests

Root cause and impact

The variant-specific decoders sliced at the ML-KEM component boundary before checking the input's total length. Inputs shorter than 2,400 bytes for X25519MlKem768Draft00PrivateKey, or shorter than 1,184 bytes for the two hybrid public-key types, therefore caused an indexing panic instead of returning the existing InvalidPrivateKey or InvalidPublicKey error.

The public PrivateKey::decode and PublicKey::decode entry points delegate to these functions. This is an input-validation and availability issue for callers that decode untrusted keys without isolating Rust panics; it does not bypass key validation or compromise cryptographic secrets.

The fix first converts the complete input slice to a reference to the expected-size byte array. Only after that succeeds is the key split into its two components.

Validation

• cargo test -p libcrux-kem --locked
• cargo check -p libcrux-kem --no-default-features --locked
• rustfmt --check
• duplicate search across existing libcrux issues and pull requests

Strict Clippy with -D warnings also reaches the package, but is currently blocked by pre-existing large_enum_variant and useless_conversion warnings in unchanged code.

AI assistance disclosure

OpenAI Codex was used to locate and reproduce the unchecked-slice behavior, implement the focused patch, write the regression tests, and draft this description. The concrete behavior and patch were validated with the commands above. This pull request is opened as a draft for final human review.