Bound gzip decompression in ingest to prevent decompression-bomb DoS

[VasiliyRad]

Summary

• /v1/ingest decompressed Content-Encoding: gzip bodies with a single gzip.decompress() call, which fully materializes the output before any size check runs. A holder of a valid ingest token could send a small, highly-compressible payload (~1000:1 ratio is trivial with gzip) that expands to gigabytes in memory, past MG_MAX_BODY_BYTES, before the existing post-decompression size check ever fires — a cheap way to OOM the server for every integration sharing that token.
• Replaced it with _gunzip_bounded, which decompresses via zlib.decompressobj(...).decompress(data, max_length=...) and aborts (413) as soon as running output exceeds the configured limit, so peak memory stays close to the limit regardless of the true decompressed size.
• Preserves existing behavior for all legitimate traffic: the decompressed-size cap was already MG_MAX_BODY_BYTES before this change (just enforced too late) — this PR does not introduce a new limit, only enforces the existing one earlier.

Test plan

• Added server/tests/test_gunzip_bounded.py: happy-path round-trip, exact-boundary (limit vs. limit+1), a payload spanning multiple internal decompression rounds (regression guard for an unconsumed_tail handling bug caught during review of my own first draft), a real ~1000:1 decompression bomb rejected without full expansion, and malformed-gzip handling.
• Verified red→green locally: new tests fail against the pre-fix code, pass after the fix.
• Full existing suite (26/26, including the pre-existing test_gzip_ingest end-to-end round-trip) passes locally against Postgres 14 — no regressions to legitimate gzip ingest traffic.

🤖 Generated with Claude Code

[VasiliyRad]

@calebjohn24, @jalexray, can you take a look? Can you add me as a contributor to the repo?