V04 gzip-cap regression test in pkg/util/http_test.go passes whether or not the new decompressed-size cap is in place

[friedrichg]

Describe the bug

The gzip decompression-bomb regression test in pkg/util/http_test.go:245 (added with PR #7515 / V04) does not actually exercise the new decompressed-size cap. On the unpatched code path the gzip branch still reads the whole 1 MB into the buffer and then the pre-existing len(body) > maxSize check returns an error, so assert.NotNil(err) is satisfied either way. The test's table-driven counterpart has no gzip case either.

The new code wraps the gzip reader in io.LimitReader(gzReader, int64(maxSize)+1) (pkg/util/http.go), bounding decompressed output. The test as written cannot distinguish that wrapper from the previous behaviour, so a regression that removes the wrapper would not be caught.

To Reproduce

1. Locally revert the io.LimitReader wrap added by PR security: limit decompressed gzip output to prevent DoS via decompression bomb #7515 in pkg/util/http.go (and the equivalent in pkg/util/push/otlp.go).
2. Run go test ./pkg/util/....
3. Observe the test still passes.

Expected behavior

Make the test bite by:

• Asserting the specific size-limit error (messageSizeLargerErrFmt, via errors.Is) rather than just non-nil.
• Wrapping the source in a byte-counting io.Reader and asserting at most maxSize+1 bytes are pulled from the gzip reader (proves the LimitReader is in place).
• Adding the gzip case to the table test with both an under-cap and over-cap payload.

Environment:

• Master and release-1.21 (V04 backport in PR Backport security audit fixes (V01-V07), snappy gRPC fix, and stream push panic fix to release-1.21 #7574).

Additional Context

• Originally flagged by @sandy2008 in PR Backport security audit fixes (V01-V07), snappy gRPC fix, and stream push panic fix to release-1.21 #7574 review (carryover from security: limit decompressed gzip output to prevent DoS via decompression bomb #7515).