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 assert.NotNil(t, err). That passes whether or not the cap is present:
decompressRequest's deferred len(body) > maxSize check rejects the oversized
body regardless, so the test never exercised the new wrapper and could silently
go to a no-op if the cap were removed.

This makes the test bite by asserting decompression stays bounded: with a tiny
gzip payload that inflates to 32 MB, the call must allocate under ~1 MB, which
only holds when the inner cap stops decompression early. Removing the cap blows
past the bound and fails the test (verified: ~16.8 MB allocated vs the 1 MB
bound).

It also adds TestParseProtoReader_Gzip covering the under-cap decode (passes)
and over-cap rejection, since the TestParseProtoReader table had no gzip case
at all.

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)

[krunaljain]

TotalAlloc is a process-wide counter. Is this assertion robust if other goroutines allocate during the call, or if the package's tests run with in parallel?

[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.