Fix reflink cloning on filesystems with large block sizes such as ZFS

[folbricht]

Fixes #353

Problem

Tests (and real extraction with seeds) fail on ZFS-backed storage with invalid argument or resource temporarily unavailable errors from CloneRange. Two separate causes:

ZFS reflink semantics. OpenZFS 2.2+ implements FICLONERANGE, so the 0-byte CanClone probe succeeds, but real clones are much stricter than on btrfs/XFS: offsets must be aligned to the recordsize (128k by default, reported as st_blksize), and cloning a range that hasn't been committed to disk yet returns EAGAIN (zfs_bclone_wait_dirty=0 default) — which is exactly what happens when the null-seed clones from its freshly written zero blockfile. On pre-2.2 ZFS the ioctl didn't exist, the probe failed, and everything quietly copied instead, which is why this is new.

A latent bug in the clone math, exposed by 128k blocks. fileSeedSegment.clone() and nullChunkSection.clone() assume every segment contains at least one full aligned block. That always holds with 4k blocks and ≥16k chunks, but not with 128k blocks. For segments smaller than a block:

• alignLength underflows (uint64), producing absurd clone lengths,
• the head/tail copies write outside the segment, clobbering neighboring data,
• when alignLength == 0, FICLONERANGE is called with length 0, which the kernel defines as "clone to the end of the source file" — silently overwriting the target far beyond the segment.

The last two can corrupt output on any filesystem given a large enough st_blksize.

Fix

• Ranges that contain no full aligned block are now copied instead of cloned (also avoids the underflow / zero-length cases).
• Any CloneRange failure now falls back to copying that range instead of failing the extraction, the same approach coreutils cp takes. The null seed skips the copy entirely when the target is still blank.
• seed.go gains a small cloneRange indirection so tests can simulate filesystems where the probe passes but cloning fails; new tests cover the fallback and small-segment geometry.

Verification

Reproduced and verified on a real ZFS pool (Ubuntu 24.04 VM, zfs-2.2.2, zfs_bclone_enabled=1, 128k recordsize):

• Unpatched binaries reproduce both reported failures with identical stack traces.
• Patched binaries pass the full library suite and all TestExtractCommand subtests on ZFS.
• Tracing FICLONERANGE calls confirms properly aligned ranges are still reflinked on ZFS (verified via zpool get bcloneused), so ZFS keeps the dedup/speed benefit rather than degrading to copy-only.

go test ./... also passes on ext4.