bench: add a 'fragmented' profile, the only one with real extent counts

[martinus]

Why

Every existing profile generates ~1 extent per file — and so does a real source tree. Measured on the actual bench-dedupe.py source:

~/git/linux, 3000-file sample:  mean 1.17 extents/file, median 1, p99 2, max 10

At E=1, an O(E²) per-file scan and an O(E) one are the same work. So per-file extent-list cost was invisible across the whole harness: the get_extent() scan fixed in #134 was 49% of all CPU on a fragmented file, and nothing here could see it — nor would anything catch a reintroduction.

This also answers "should we re-run the larger-than-RAM benchmark after #134?": no. Its source tree is 1.17 extents/file, so that fix cannot move it, and docs/benchmarks.md stays accurate as published. The gap is a missing workload, not a stale number.

What

fragmented: 8 x 512 MiB files, each shredded into ~32k extents by rewriting one block per 32 KiB stride in random order (btrfs CoW makes each rewrite its own extent; ascending order lets the allocator merge them straight back).

That's the shape a long-lived dedupe target degrades into — dedupe fragments what it shares — and it's closer to the NAS/backup workload oans is positioned for than a kernel checkout is.

Adds one Profile field (frag_stride_kb) and a key to PROFILES, per the harness's "add a key, nothing else changes" contract. No new bench-* script.

Two ordering constraints, both found by getting them wrong

• sync before the rewrites. Rewriting still-dirty pages replaces them in place, no CoW happens, and writeback lays the file out contiguously. My first version produced ~6k extents instead of ~32k and measured nothing at all — base 1.50 vs fix 1.48 wall median, a clean null result from a broken fixture. Same trap as the missing sync between rm and cp in bench-dedupe.py.
• Fragment after the cp pass, never before. cp writes its destination sequentially, so copying a fragmented original yields a contiguous copy.

_mean_extents() prints the achieved count at build time, so a silently-unfragmented tree announces itself instead of quietly measuring nothing.

Verification

A/B against the pre-#134 binary, 7 warm rounds:

io-threads	wall (base → fix)	user (base → fix)
8	2.51 → 2.50 (nothing)	3.05 → 1.05 (2.9x)
2	3.32 → 2.51 (1.3x)	2.75 → 0.96 (2.9x)

user always separates. For wall to separate, pair with --io-threads 2 — with 8 files over 8 threads it's one file per thread, so the extra CPU just overlaps. That's the same pairing convention bigfile already documents, and it's in the profile note.

Tree generation is reproducible (32,768 extents/file on a clean regenerate) and the manifest cache correctly skips regeneration on re-runs. scripts/verify.sh passes.