drpc: snappy compression decode allocation bomb

A crafted KindMessage payload of ~6 bytes can trick snappy.Decode into attempting a 4 GiB allocation on 64-bit platforms. snappy.Decode reads the claimed decompressed length from the header and allocates the full buffer before validating the rest of the payload. There is currently no size cap on decompressed output, unlike gRPC's MaxRecvMsgSize.

Untested fix: call `snappy.DecodedLen(src)` in `drpcwire.Decompress` and reject payloads exceeding a configurable limit before decoding. Could gate on `Options.MaximumBufferSize` or a dedicated `MaxDecompressedSize` field.

Low severity for authenticated node-to-node traffic, but cheap insurance against a buggy or compromised peer OOM-killing the receiver.

Jira issue: CRDB-65819

Start at drpcwire.Decompress and inspect how snappy.Decode currently handles the payload length. Compare using snappy.DecodedLen with Options.MaximumBufferSize or a dedicated MaxDecompressedSize limit, then add coverage showing oversized decompressed output is rejected before allocation and that normal decoding still works.

Written by the indexing model from the issue text.