does this force writing output (if available), I think this should lead to FlushCode.SyncFlush to the native API

We should be more clear which default we mean.

This would fail on valid native compression levels not covered by the CompressionLevel enum. Instead I think it should check if the value is is < -1 or > 9 to throw out of range instead.

Also to add on to the above, now those who want compression levels that just happen to == a value in the CompressionLevel enum will now not be able to use those compression levels either. Perhaps a solution to this is to expose a version of the ctor with CompressionLevel and a version with int that gets casted to ZLibNative.CompressionLevel after a range check.

The GetMaxCompressedLength calculation adds excessive overhead. The compressBound() function used by DeflateEncoder.GetMaxCompressedLength already includes 6 bytes for zlib format wrapper (2-byte header + 4-byte Adler32) in its 13-byte constant overhead. For GZip format with an 18-byte wrapper (10-byte header + 8-byte trailer), only 12 additional bytes are needed (18 - 6 = 12), not 18.

Change line 85 to: return baseLength + 12;

While the current overestimation is safe and doesn't cause correctness issues, it wastes memory by requesting buffers that are 6 bytes larger than necessary.

Parameter validation order could be optimized. Currently, compressionOptions is validated and used to compute windowBits before stream is validated for null. If stream is null, the windowBits computation is wasted work.

Consider reordering to validate both parameters first:

ArgumentNullException.ThrowIfNull(stream);
ArgumentNullException.ThrowIfNull(compressionOptions);

int windowLog = compressionOptions.WindowLog == -1 ? DeflateEncoder.DefaultWindowLog : compressionOptions.WindowLog;
int windowBits = -windowLog;

InitializeDeflater(stream, ...);

This matches the pattern in the internal constructor at line 68-74 and fails fast with minimal wasted work.

Interop signature for compressBound uses uint for both input and return. zlib-ng's compressBound takes/returns z_uintmax_t (potentially 64-bit), so this P/Invoke can truncate the bound on 64-bit platforms. Consider switching to nuint/ulong (matching ZSTD_compressBound patterns) together with a native export that returns a pointer-sized/64-bit value.

GetMaxCompressedLength allows inputLength up to uint.MaxValue, but the underlying compressBound() can produce a bound larger than 4GiB for large inputs. With the current uint-returning interop this can wrap/truncate and return a value that is not an upper bound. Either change the interop/native export to return a 64-bit value, or further restrict inputLength so the computed bound is guaranteed to fit in the chosen return type.

ZLibCompressionOptions.WindowLog is a new public configuration knob, but there are no corresponding unit tests validating default value, accepted range (-1, 8-15), and expected ArgumentOutOfRangeException parameter name for invalid values. Adding coverage alongside the existing CompressionLevel/CompressionStrategy option tests would help prevent regressions.

The comment implies ZLib requires CMF byte 0x78, but valid CMF values vary with window size (0x78 is just the common 32KiB-window case). Consider rewording to state that the first byte must be a valid CMF for deflate+window size, without implying a single fixed value.

RoundTrip_AllCompressionLevels doesn't assert the OperationStatus (or bytesConsumed/bytesWritten) from Compress/Decompress. If these calls start returning DestinationTooSmall/NeedMoreData/InvalidData, the test failure will be less actionable (or could miss partial-progress scenarios). Consider asserting status == Done, consumed == input.Length, and written == input.Length for each iteration.