test: make gzip decompression-bomb regression test actually bite

[anxkhn]

What this PR does:

TestParseProtoReader_GzipDecompressionBomb was added in #7515 to guard the io.LimitReader(gzReader, maxSize+1) cap on gzip decompression, but it only asserted that an error was returned. That passes whether or not the cap is present because the oversized body is rejected either way.

This replaces that test with a deterministic white-box regression test that calls decompressRequest directly and asserts the buffered body never exceeds maxSize+1. Unlike the earlier runtime.MemStats.TotalAlloc approach, this checks a local slice length, so unrelated process allocations cannot affect it. Removing the cap inflates the test payload to several megabytes and fails the assertion.

It also adds TestParseProtoReader_Gzip covering successful under-cap decoding and over-cap rejection through the public API.

Test-only change; no production code, config, or flags touched.

AI assistance: this change was prepared with help from an AI coding assistant. I reviewed every line, validated the regression behavior locally, and can explain the design (per GENAI_POLICY.md).

Which issue(s) this PR fixes:
Fixes #7581

Checklist

• Tests updated
• Documentation added (n/a, test-only)
• CHANGELOG.md updated (n/a, not user-facing)
• docs/configuration/v1-guarantees.md updated (n/a, no flags)

[anxkhn]

Good point, TotalAlloc is process-wide and monotonic, so a parallel test or a background goroutine allocating during the call could inflate the delta and make the bound meaningless. Digging in, the source-read count doesn't work either: an outer io.LimitReader already caps the compressed input to maxSize+1, so bytes read from source are nearly identical with or without the inner cap (4096 vs 4097) and both paths error. The only signal that reflects the guard is how much gets decompressed into memory. I replaced the memory heuristic with a white-box TestDecompressRequest_GzipDecompressionBomb that calls decompressRequest directly and asserts len(body) <= maxSize+1. It is deterministic and parallel-safe (just a local slice length, no runtime stats) and still bites: dropping the io.LimitReader(gzReader, maxSize+1) cap inflates the buffer to ~4 MB and fails with 4204111 is not less than or equal to 4097.

[SungJin1212]

Thanks for improvements