fix(python-package): accept ZIP64 wheels on CPython 3.13.14

[hseshadr]

TL;DR

python-package rejects every valid ZIP64 wheel on CPython 3.13.14, the Python that central CI pins. Its own gate is red there. This fixes the probe. The new hosted module gate (#run-module-gates, stacked on this PR) found it on its first run.

Claim touched: "the release probe accepts exactly the wheels a real build produces and rejects anything with bytes outside the ZIP framing."

What broke

zipfile._EndRecData changed between CPython patch releases. For a ZIP64 archive it now reports the offset of the ZIP64 end record, not the classic end record:

CPython	reported offset	classic end record	ZIP64 end record
3.13.5	286	286	210
3.13.14	210	286	210

The probe used that offset for its physical-EOF and concatenation checks. On 3.13.14 it computed the wrong end of file and raised wheel physical EOF differs.

Fix

The classic end record always ends the file, so the probe now derives its offset from EOF (size - 22 - comment_size) and still checks the PK\x05\x06 signature there. Trailing bytes still fail closed on both versions. A new test covers a ZIP64 wheel with trailing bytes.

Evidence

Check	Result
test_should_observe_bounded_forced_zip64_wheel, CPython 3.13.14, before	red: 1 failed, 22 passed (wheel physical EOF differs)
same, CPython 3.13.14, after	23 passed
same, CPython 3.13.5, after	23 passed
poe gate (python-package), local	green, 134 passed, 96.95% total coverage
Mutation: drop the EOF-derived offset (return zipfile's record unchanged)	this is the "before" state, red on 3.13.14
git merge-tree vs #47, #48, #50, #51	clean (all four)

Merge order

Merge this before the stacked ci/run-module-gates PR. That PR runs every module gate on CPython 3.13.14 in hosted CI.

🤖 Generated with Claude Code

https://claude.ai/code/session_015oBArfm762nN1r4F4Fst5a