tls_codec: enforce the mls vector length limit in DeserializeBytes - #2461

With the mls feature, variable-length vector lengths are limited to 2^30 - 1. RFC 9420 2.1.2 allows only the 1-, 2- and 4-byte length encodings, and says vectors whose length starts with the 11 prefix (8 bytes) "MUST be rejected". quic_vec.rs enforces this in ContentLength::new, but only the Read path goes through it. DeserializeBytes for ContentLength builds Self(value) directly, so the two paths disagree:

// tls_codec with features ["mls", "std"]; 8-byte length header for 2^30 (minimal for that value)
let mut input = vec![0xc0, 0, 0, 0, 0x40, 0, 0, 0];
input.resize(8 + (1 << 30), 7);

VLBytes::tls_deserialize(&mut input.as_slice())   // Err(InvalidVectorLength)
VLBytes::tls_deserialize_bytes(&input)             // Ok(1073741824-byte vector)

With fewer content bytes than declared, the bytes path reports DecodingError("16 bytes were read but 1073741824 were expected") for VLBytes (and hits the debug_assert_eq! that #2414 removes in debug builds), and EndOfStream for Vec<u8>, instead of InvalidVectorLength. VLByteVec and Vec<T> use the same ContentLength path.

The fix calls ContentLength::new in DeserializeBytes too, so both paths reject the length header itself. Without mls, new is a no-op, so nothing changes there.

Test: mls_length_above_30_bits_is_rejected in tests/decode_bytes.rs (#[cfg(feature = "mls")]) checks VLBytes, VLByteVec and Vec<u8>. It fails on master. The tls_codec.yml matrix passed locally: powerset tests on stable and 1.85, wasm32/thumbv7em builds, derive tests, benches, fuzz build, fmt, clippy. I skipped the i686 job because this machine has no multilib.

This PR was produced by AI agents (Claude) and reviewed by me before submission.