zip: clamp the input count before the 32 bit avail_in fields

archive_read_open_memory() gives the reader the whole buffer as one
block. __archive_read_ahead() can therefore report more than 4 GiB of
available input.

The deflate and bzip2 entry readers cast that ssize_t count straight
into avail_in, which is 32 bits wide. Exactly 4 GiB of input truncates
to zero. inflate() then returns Z_BUF_ERROR, and the archive fails with
"ZIP decompression failed (-5)". The bzip2 path is worse: libbz2 reports
success for an empty input, the reader makes no progress, and
archive_read_data() loops forever.

Clamp the count first. This is the same guard that the gzip and bzip2
read filters already use.

The mac metadata reader casts to uInt too, but the count there is
already limited to ZIP_MAX_METADATA, so it cannot overflow.

To reproduce: build a streaming ZIP entry that sets general purpose flag
bit 3, so the sizes live in a trailing data descriptor and the reader
cannot clamp the input to the entry size. Put it at the head of a buffer
sized so that exactly 2^32 bytes remain when decompression starts, then
call archive_read_open_memory() on that buffer.