Cram: matoleo yote na matoleo ya zamani

Security
- Extraction no longer writes through a symbolic link already in the destination. If
out/target.txt was a link to a file elsewhere and the archive carried target.txt, extracting
into out truncated the link's target and wrote the entry's bytes into it, outside the
destination. Every release from 1.0.0 to 1.3.1 did this, in cram x, in streamed extraction and
in cram-extract. An existing path is now overwritten only if it is a regular file; a link, a
FIFO or a device is left as it is and the entry is reported as a failure naming the cause. The
check is made on the opened handle, so there is no window between checking and writing. A
pre-existing FIFO also used to hang the extraction, and now fails the entry instead. The refusal
is tested on Linux; on Windows, where planting the link needs symlink privilege or Developer Mode,
the same test has not yet run. Reported by @anish833.
Still followed, on purpose: a link to a directory above the final component (out/sub -> elsewhere, entry sub/x). Cram never creates a link from an archive, so one inside the
destination was put there by the user or another program.

Fixed
- A .zip whose entries use Zstandard (method 93) can now be read. Every such entry previously
failed with compression method not supported: 93 while the rest of the archive extracted around
it, so a real archive came out partially populated with thousands of individual errors rather than
one clear refusal. Repackers have largely moved to zstd-in-zip because it is much faster than
DEFLATE at a similar ratio, so this is common in the wild rather than exotic. It had never worked
in any release.
The exclusion was deliberate and its reason had expired: the ZIP dependency took pure-Rust features
only so the default build needs no C toolchain, and that was written before Cram linked C zstd at
all. It does now, and the zip crate wants the same crate at the same version, so reading method
93 rides on the existing zstd-c feature and costs the shipped binaries nothing. A default
cargo install cram-cli build is unchanged and still has no C dependency, so it still cannot
read these archives.

Added: a duplicate scan now reports what it has found while it is still running, instead of saying
nothing for the minutes it takes to walk a drive.

Fixed: a look-alike group could swallow hundreds of unrelated images. Grouping was by perceptual
hash alone, unioned, which is single-linkage clustering, so one bridging pair merged two sets that
resembled each other not at all. A candidate pair is now verified against the pixels.

Fixed: a cancelled extraction removed more than it wrote. It now takes back only files and
directories that did not exist when it created them.

Fixed: a directory cycle walked forever. Past 1,000 levels the walk checks file identity and stops
when it reaches somewhere it has already been.