hatchzip archive extraction and collision handling, specifically for symbolic links and directories.

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

An archive that pairs a file below a path with a link entry at that same path passes check and then dead-ends:

- Entries: d/inner.txt (file) and d (symlink, target anywhere). Crafted copies: dircollide.zip, symlink.zip, symlink.tar. All three hit the same end state.
- extract writes the file, creating a real folder d, consumes the whole archive down to zero bytes, then fails at the last step: error: creating link 'd': Is a directory (os error 21).
- The journal says every entry is extracted, so both recovery routes fail forever. Running extract again repeats the same error. restore refuses with "all entries are already extracted. Run extract to complete the extraction", a state that can never complete.

The extracted files are present and correct. What is lost is the link itself and the archive; the unextracted link entry survives only in the .hatchzip-tail sidecar, and the CLI warns elsewhere that deleting the sidecars loses data.

Root cause, as far as I traced it: in Job::build, Kind::Dir is excluded from the duplicate-path check, and the parent folders that file entries force into existence are never checked against link paths.

Expected: refuse the archive before anything is deleted, archive intact, the way other hostile archives are refused.