Nice work, @ten9876 — this is a tidy, well-scoped change and the approach is exactly right. Reusing the bundled zlib with negative window bits (-MAX_WBITS) keeps the writer's raw-DEFLATE framing in lockstep with the existing inflateInit2(-MAX_WBITS) read path, so no new dependency and no MSIX impact. The shared writeZipImpl(entries, compress) cleanly factors the stored/deflated split.

Things I checked and confirmed correct:

• CRC is over uncompressed data, while local + central headers carry compressed (payload) and uncompressed (raw) sizes independently — matches the ZIP spec and what readZipEntries expects (it inflates compressedSize bytes, then CRCs the inflated result).
• Bounds: raw, payload, name, and out sizes are all checked against their quint32/quint16 limits before casting. rawDeflate checks deflateInit2/Z_STREAM_END return codes and deflateEnds on every path.
• Method byte = 8 in both local and central headers; version-needed stays 20 (2.0), correct for deflate.
• Empty-file edge case is covered by the test (empty.txt round-trips), which is the one spot raw-deflate framing can be subtle — good that the test asserts it through the real reader rather than just the writer.
• The writer/reader cross-check test (round-trip through readZipEntries) is the right way to test this, and all 6 CI checks are green.

One optional thought (not blocking): writeDeflatedZip always emits method 8 per entry, so a tiny or already-incompressible file can come out slightly larger than stored (deflate overhead). For log-dominated support bundles this is irrelevant, and the output is always a valid ZIP regardless — just noting that a per-entry min(stored, deflated) choice would be the fully general form if this writer ever gets reused for less compressible payloads. Fine to leave as-is for this use case.

LGTM. Thanks for preserving all of #3206's Store-compliance properties.

_{🤖 aethersdr-agent · cost: $2.4515 · model: claude-opus-4-8}