Compress(byte[]) throws for incompressible input over ~280 KB: GetMaxCompressedLength undercounts Deflate/Gzip/ZLib overhead #39

What's wrong

The Deflate, Gzip, ZLib and Brotli providers compute GetMaxCompressedLength as n + ((n / 65535) + 1) * 5 + 64 (for example in Essentials.CompressionProviders.Deflate/DeflateCompressionProvider.cs:23-24). The remark says this is because incompressible input goes into 64 KB stored blocks with a 5-byte header each.

zlib at the default and Optimal level doesn't do that. It closes a block every time its literal buffer fills, which is roughly every 16 KB. So the per-block overhead comes about four times as often as the formula allows.

For random data, raw deflate at level 6 (the same as .NET Optimal) gives:

Gzip and ZLib add their own wrapper on top of this, so they exceed the bound too.

Why it matters

ICompressionProvider.Compress(ReadOnlySpan<byte>) (Essentials/ICompressionProvider.cs:~55) allocates its buffer from GetMaxCompressedLength through ProviderHelpers.ExecuteToExactArray. For inputs above about 280 KB, TryCompress then returns false, and the caller gets InvalidOperationException("Compression failed to produce output with the allocated buffer."). This affects any already-compressed, encrypted or random payload, such as images, archives or ciphertext.

It also breaks the contract that a destination sized from GetMaxCompressedLength guarantees TryCompress succeeds.

ProviderContractTests.Compression_Bound_Holds_For_Incompressible_Input only exercises 4096 bytes, which is why it still passes.

Suggested fix

• Use zlib's deflateBound: n + (n >> 12) + (n >> 14) + (n >> 25) + 13, plus the container overhead (+6 for zlib, +18 for gzip).
• For Brotli, use BrotliEncoder.GetMaxCompressedLength(n).
• Compute in long, and throw or clamp near int.MaxValue so the bound can't overflow.
• Extend the contract test to 1 MiB and 10 MiB of random data for every provider.