hyperion-minecraft-proto: Error has no variant for a collection longer than its codec's cap

[andrewgazelka]

Several StreamCodecs in 26.2 cap a collection explicitly, e.g. ServerboundSelectKnownPacks.STREAM_CODEC is KnownPack.STREAM_CODEC.apply(ByteBufCodecs.list(64)) while the clientbound twin is unbounded. That cap is a resource guard on serverbound input and belongs in the decoder.

crates/hyperion-minecraft-proto/src/error.rs has no variant that says "a collection declared more elements than this field permits". The closest are NegativeLength (wrong meaning) and UnexpectedEof (only fires when the frame is genuinely too short). Reusing either would report the wrong thing.

Concretely, in #968 SelectKnownPacks::decode enforces only the frame-derived bound: the declared count is checked against remaining_len() / 3, so a 32767-byte serverbound frame still admits ~10k packs where vanilla admits 64. MAX_SERVERBOUND_KNOWN_PACKS is exported so a caller can check, which is a footgun rather than a guard.

Suggested fix: add

/// A collection declared more elements than its codec permits.
TooManyElements {
    /// Element count declared.
    count: usize,
    /// Maximum the field permits.
    max: usize,
},

and have the list helpers take the cap. ByteBufCodecs.list(n) and ByteBufCodecs.map(..., n) appear in enough play packets that this will be needed again as play is filled in.

Filed by Claude while implementing #968.