Reject a malformed version message instead of panicking

[plaidfinch]

CAVEAT LECTOR: This PR was generated by Claude Fable 5.

Problem

The server parses the client's first attestation-protocol message with version_bytes[..4], which panics if the message body is shorter than 4 bytes. Any TLS-authenticated peer can trigger this with ~8 bytes (a length prefix of 2 followed by two bytes).

Fix

Parse the version with a checked conversion and reject anything but exactly 4 bytes as Error::ProtocolVersion.

One deliberate strictness change: a version message longer than 4 bytes was previously accepted with the trailing bytes ignored. No client of either protocol version has ever sent one (both send exactly CURRENT_PROTOCOL_VERSION.to_le_bytes()), so there is no interoperability change.

Testing

New regression test short_version_message_rejected: a TLS-authenticated client sends a 2-byte body; the server must return Err(ProtocolVersion) rather than panic.

Verified on illumos: cargo test 7/7, CI-style clippy clean.

Relationships

Independent of #108 and #109; the three can land in any order.

[hawkw]

The combination of this change and #108 kinda makes me wonder if it might be valuable to have a version of recv_msg that's like recv_msg_exact<T, {const N: usize}> that returns a [u8; N] and rejects messages of greater length at the protocol level, and doesn't allocate a potentially arbitrarily-large Vec<u8>. I'd have to look closer at the surrounding code to see if there's more than exactly one place where we'd use that, though.