README: bring up to date with v1.4.0/v1.5.0, fix a stale benchmark figure

[martinus]

The README was last substantively updated in #118, two releases ago. It was
missing everything shipped since, and carried one figure that no longer matched
docs/benchmarks.md.

One factual error

The path-hash-index row claimed a smaller hashfile of "41 vs 73 MiB on the
benchmark tree". Neither number appears anywhere in docs/benchmarks.md, which
measures 39.7 vs 70.9 MiB — and that measurement comes from the
larger-than-RAM tree, not the 2.07M-file / ~230 GiB tree the surrounding table
describes. Both the numbers and the attribution are corrected.

The table intro had the same problem in miniature: it said "benchmarked on real
btrfs data (2.07M files, ~230 GiB)" while several rows draw from the other
benchmark. It now names both trees up front.

Missing since v1.3.0

Each verified present in the tree, not taken from a commit title:

• Paths beyond PATH_MAX are hashed and deduped rather than skipped (Actually hash & dedupe files whose absolute path exceeds PATH_MAX (follow-up to #108) #117, Hash & dedupe files whose absolute path exceeds PATH_MAX (#117) #124, Fix the flaky partial-mode UAF (#123), plus three PATH_MAX leftovers #128)
• The streaming dedupe pipeline (dedupe: streaming pipeline with a persistent pool (Stage 2) #116) — the Stage 2 architecture had no bullet at all
• The O(extents²) fragmented-file scan fix (scan: fix quadratic extent scan on fragmented files (2x on 65k-extent file) #134)
• The two dedupe-phase races — block-hash-search UAF (Flaky use-after-free in --dedupe-options=partial drain (find_dupes reads a filerec freed by dedupe_drain) #123) and the TSAN-found pool lifetime bug (Make ThreadSanitizer usable, and fix the use-after-free it found #129)
• clang ASAN/UBSAN/TSAN CI legs, warnings-as-errors, and make check-all — the CI bullet mentioned only valgrind
• --cpu-threads, absent from both CLI lists despite being in --help and the man page
• Progress polish: scan-phase hashing throughput (progress: show hashing throughput during the scanning phase #120), idle-worker display (progress: show hashing workers as idle when the queue starves #143)

Consistency and readability

• Dropped the standalone larger-than-RAM [!NOTE]. The same ~13× claim appeared
  three times (Why-oans table, that note, "vs upstream duperemove"); its unique
  content — peak RSS and hashfile size — is now a row in the speedups table,
  where the reader is already comparing figures.
• Marked upstream issue references as upstream #NNN throughout. Bare #331,
  #374, #376, #387 now read as oans issues, since oans has its own numbers
  in that range. Matches the style already used for #396/#407.

Checks

All nine internal links resolve; the #larger-than-ram-dedupe and
#what-the-fork-changes anchors match real headings; and the headline numbers
(~11 min → ~92 s, ~294 → ~188 s, 13.8 vs 179.7 s) were each checked against
docs/benchmarks.md.

I did not run scripts/verify.sh: the diff is markdown-only and touches no
code, so the build/test/valgrind gate has nothing to exercise. Say the word if
you'd rather it ran anyway.

Left alone deliberately, as they look intentional rather than stale: the Debian
dep list omitting libatomic (added for Fedora 41 in #82; build-essential
covers it on Debian), and "Requires Linux 3.13+".

🤖 Generated with Claude Code