Inventory incomplete download metadata

[seonghobae]

Summary

• surface .crdownload and exact .zip.partNNN files that the cloud planner previously omitted
• record browser acquisition metadata without treating it as a production date
• retain only download-origin hosts from macOS metadata, never full URLs or signed query strings
• inventory multipart gaps and block non-atomic member copies
• probe ZIP central-directory readability and block unreadable standalone archives

This is stacked on #29.

Real-data evidence

A read-only Downloads audit found more than 3 GiB outside the existing candidate set. One multipart set exposes 000,001,003,004; another exposes only 000,004. A .zip file and its .part004 peer are byte-identical, while zipinfo reports missing leading bytes. These are not safe standalone cloud candidates.

A corporate dataset ZIP also carries groupware origin-host metadata. That provenance is destination-policy context, not production-date evidence.

Validation

• npm run check — 0 errors, 0 warnings
• npm test -- --run — 5 files, 18 tests passed
• rustfmt --edition 2021 --check src/cloud.rs
• git diff --check
• cargo metadata --locked --no-deps --format-version 1
• CodeGraph re-indexed

Local full Rust compilation was deferred to remote CI because this machine is actively reclaiming disk and has no local Cargo target cache.