Bound Thunder Thrift containers before allocation

[garagon]

Summary

Keep legacy Thrift event decoding from reserving memory based only on a container count declared in the payload.

Thunder's generated readers preallocate vectors from the decoded list length. Apache Thrift's default configuration limits total message size, but it has no container-element limit and does not bind that check to the bytes in the current payload. In the unmodified code, an 11-byte event declaring 1,000,000 strings reaches Vec::with_capacity and requests a 24 MB allocation before the first string read fails.

Both legacy deserializers now use Thrift's built-in TConfiguration:

• message and string limits are tied to the actual payload length
• containers have an explicit 100,000-element ceiling
• malformed lengths fail during read_list_begin, before generated code preallocates the vector

The protobuf v2 path and generated schema files are unchanged. A legacy event containing a collection above 100,000 elements will now be rejected.

This applies to messages consumed by Thunder's Kafka listeners. It does not imply that the topic is publicly writable; reachability depends on Kafka producer access.

Validation

• A baseline allocator probe against the unmodified source confirms the 1,000,000-element payload requests at least 24 MB.
• The same payload is rejected by the changed decoder without a large reservation.
• A valid TweetEvent containing one string still deserializes correctly.
• Built the published Thunder schemas and changed deserializer in a focused Rust harness using Apache Thrift v0.23.0, the version declared by the repository's published Rust workspace: 3 tests passed.
• rustfmt --check passes.

The public repository does not include a build manifest for thunder, so a full service build is not available from this checkout.