hatchzip archive extraction logic, specifically handling duplicate entries in ZIP files.

Found in 0.1.2 (main at d8a4edbc9ec8ef84540e42408916a409a7d3c21b), confirmed by running the binary on a crafted zip.

README and docs/how-it-works.md say two entries with the same path are rejected before starting, and the engine has that check in Job::build. For ZIP it never fires: the copies collapse to a single entry before the check sees them.

Repro with collision.zip: two entries both named dup.txt, contents "one" and "two".

- hatchzip list shows 1 entry.
- hatchzip check reports 1 entry and passes.
- Extract writes "two". The last entry in the central directory wins.

Why it matters: tools that read the first copy instead (several scanners and previewers do) show different content than what HatchZip writes to disk. The harmless copy can sit where an inspector looks and the payload copy last.

Fix direction is your call: refuse duplicates where the ZIP entries are collected, or align the docs with the last-wins behavior. Reporting it as the docs-vs-behavior mismatch it is.