Check uncompressed size of deflate, bzip2, LZMA and XZ entries.

[DeNdlerX]

For deflate, bzip2, LZMA and XZ entries, the uncompressed size from the central directory was never compared with the length of the decompressed data. Once the decompression layer reached the end of the stream, its stat replaced the size from the archive with the number of bytes it had produced, so the CRC layer compared the data length with itself. Stored and zstd entries were already checked.
The fix keeps the size from the lower layer if there is one (one condition in zip_source_compress.c).

Reading such an entry now fails at the end of the data with ZIP_ER_INCONS / ZIP_ER_DETAIL_INVALID_FILE_LENGTH, as stored and zstd entries already do.
Recompressing such an entry in zip_close() now fails with ZIP_ER_DATA_LENGTH instead of writing the actual size. Entries that zip_close() copies without recompressing are not affected.

New tests read_incons_deflated_longer and read_incons_deflated_shorter read deflated entries whose CRC matches the data but whose uncompressed size is too small or too large.
Under LeakSanitizer the two new tests only pass with #591 applied, because ziptool cat hits the zip_source_free() leak fixed there.

Assisted-by: Claude Code (Opus 5.5)

[dillof]

I don't like making the decompression source worse to make validation work. The crc source should get the data to compare against when it is created. We'll restructure the code accordingly.

[DeNdlerX]

Thanks, that makes sense. Passing the expected size to the CRC source when it's created would also cover the AE-2 case in #596, since that check uses the same layer. Would you like me to rework both PRs that way, or would you prefer to do the restructuring yourselves? The regression tests should apply either way.