reject entries with a zero compressed size on entry open

[jmestwa-coder]

Zero compressed size with a non-zero uncompressed size

A crafted archive that carries the real sizes in a zip64 extended-information field slips past miniz's consistency check (which only runs when neither 32-bit size field holds the sentinel), and its extractors then short-circuit the zero compressed size and return success without touching the output, so zip_entry_read hands back 4000 bytes of untouched heap while zip_entry_noallocread reports 4000 into a 16-byte buffer it never wrote. Rejecting the inconsistent header at both read-mode opens covers the readers and the index-based delete path in one place, and keeps it apart from the directory guard in #441 which cannot reach this case; test_open_zero_comp_size_rejected fails on master and passes here.