Validate unencrypted packages before copying or mapping the entire file

[tuki0918]

Summary

Unencrypted input is consumed before BundlePack knows that it is a valid ZIP package:

• Windows copies the complete source into a system temporary file before EOCD and central-directory validation.
• macOS opens the complete package as Data with mappedIfSafe; a full allocation is possible when mapping is unavailable.

There is no physical input-size budget before these operations.

Impact

Opening a huge non-ZIP file with a .bundlepack extension can fill the Windows system volume or create severe memory and virtual-memory pressure on macOS before the package is rejected.

Evidence

• Windows/BundlePack.Core/BundlePackService.cs:209-219
• Windows/BundlePack.Core/BundlePackService.IO.cs:67-117
• macOS/BundlePack/Shared/ZipArchiveInspector.swift:54-67

Reproduction outline

Place a huge or sparse non-ZIP file on an external or network volume, rename it with the .bundlepack extension, and open it. On Windows, observe BundlePack-Opened-*.zip growing in the system temporary directory before validation fails.

Proposed change

• Open the source once with an appropriate sharing policy.
• Perform bounded tail, EOCD, central-directory, and ZIP32 physical-size preflight from that same handle.
• Reject malformed or physically impossible inputs before snapshotting or whole-file mapping.
• Snapshot only from the validated handle and enforce a derived byte limit while copying.
• Replace the whole-file Swift parser input with a bounded random-access source if practical.

Acceptance criteria

• A huge malformed or sparse input is rejected after bounded reads and without a same-size temporary copy.
• Validation and later snapshotting are bound to the same source identity.
• Tests use a synthetic stream or sparse fixture and assert an upper bound on bytes read and written.
• Cancellation remains responsive during preflight and snapshotting.

Compatibility constraints

Do not reject valid single-disk ZIP32 packages merely because they contain a legal ZIP comment. Keep the existing no-ZIP64 policy and derive physical limits from the accepted format instead of introducing an arbitrary small file-size cap.