zipfile should reject inconsistent disk information in EOCDR

Bug report

Bug description:

zipfile is explicitly documented as not handling multipart (i.e. multi-disk) ZIPs.

However, zipfile also does not check the EOCDR's state for consistency with that invariant.

Two fields are relevant (offsets are relative to the start of the EOCDR):

• "number of this disk" (offset 4, size 2)
• "number of the disk with the start of the central directory" (offset 6, size 2)

In zipfile's model, both of these should always be 0, since there's exactly one "disk."

However, at the moment, zipfile appears to silently ignore these fields and allows a parse even when they're incoherent or inconsistent with each other. For example:

import io
import struct
import zipfile

archive = io.BytesIO()
with zipfile.ZipFile(archive, "w") as zipf:
    zipf.writestr("entry.txt", b"payload")
data = bytearray(archive.getvalue())
eocd = data.rfind(zipfile.stringEndArchive)
struct.pack_into("<H", data, eocd + 4, 1)
with zipfile.ZipFile(io.BytesIO(data)) as zipf:
    print(zipf.namelist())

This exposes ['entry.txt'], whereas other parsers (Rust's zip and async_zip, Info-ZIP, and 7-ZIP) reject the ZIP as malformed.

CPython versions tested on:

CPython main branch

Operating systems tested on:

No response

Linked PRs

• gh-155814

Comienza reproduciendo el ejemplo de BytesIO del issue y siguiendo el análisis de EOCDR de zipfile, centrándote en los dos campos de número de disco de los offsets 4 y 6. Se considera completado cuando los archivos comprimidos malformados con información de disco distinta de cero o incoherente se rechazan en lugar de analizarse correctamente; el issue enlaza la PR gh-155814 para el trabajo en curso.