Every hardlink of a file is read and SHA-256-hashed in full, so a snapshot tree re-reads each unchanged file once per snapshot even when it has no duplicate #196

What happens

The size pre-filter from #147 (FileHasher.HashPossibleDuplicates, FileDeduplicator/FileHasher.cs:33-38) groups paths by size. N hardlinks of one file all share that size, so they pass as "possible duplicates" and HashFiles (FileHasher.cs:40-70) reads the same inode end to end N times. Only afterwards does Deduplicator.CollapseSameFile (Deduplicator.cs:78-84) recognise them as one file and conclude there is nothing to deduplicate.

Repro (HEAD 0708fa5): one 50 MB file hardlinked into 4 snapshot directories, no other file of that size:

Found 5 file(s).
Hashing files...
  Hashed: video.bin -> 9f854cf82d19...
  Hashed: video.bin -> 9f854cf82d19...
  Hashed: video.bin -> 9f854cf82d19...
  Hashed: video.bin -> 9f854cf82d19...
No duplicate files found.

200 MB read to conclude there are no duplicates; the correct cost is zero reads, because only one file has that size.

Why it matters

Hardlink-heavy trees (rsnapshot, cp -al, rsync --link-dest, Time Machine-style backups) are exactly the trees #132 and #190 are about. In such a tree almost every file is a multi-linked unchanged file, so the run reads the whole backup volume once per snapshot — on the cold disks, USB drives and network shares the #147 remarks say dominate run time — just to discover that the links are the same file.

Suggested fix

In HashPossibleDuplicates, read FileIdentity for each path and group by identity before the size check:

• count distinct identities per size bucket when deciding whether a size is unique;
• hash one representative per identity and assign its hash to every path sharing that identity, so FileHashes still maps every path and Stats/Deduplicate removes one name of a hardlinked duplicate and reports the space as reclaimed, but frees nothing and the next Scan finds the same duplicate again #190 handling is unchanged.

Acceptance criteria

• A file with N hardlinks and no other file of its size is not read at all.
• A file with N hardlinks that does share a size with a different file is read once, not N times.
• Existing hardlink tests (SameFileTests, Hardlinked files are deduplicated like independent copies, risking silent data loss in snapshot/backup trees #132/Deduplicate deletes the only copy of a file that the scan reaches at two paths (bind mount, directory mounted twice) #139/Stats counts hardlinks as duplicate files and double-counts their size, so it reports "Duplicate files: 1, Duplicate groups: 0" where Scan finds no duplicates #189 coverage) still pass.