file_scan: handle sparse files with a trailing hole (#374)

[martinus]

What this fixes

A file whose data ends before EOF (data followed by a hole up to end-of-file) has a last mapped extent that ends before filesize; FIEMAP never reports the trailing hole. process_extents() then broke in two ways once file_off reached the hole:

• dummy = ext_end_off - filesize underflowed (size_t), because the last extent ends before filesize, so file_off + dummy == ext_end_off never held and the last real extent was never stored;
• the next get_extent() returned NULL, which printed process_extents: unable to get extent and returned 1, so the caller declared the file "changed" and abandoned it.

What happens without the fix

Any file with a trailing hole is silently never hashed or deduped — it's skipped every run.

The fix

Only subtract the past-EOF overshoot when the extent actually runs past filesize, and treat a NULL from get_extent() as "past the last extent = trailing hole, stop cleanly" rather than an error. Verified that trailing-, middle- and leading-hole files all scan and dedupe with data preserved byte-for-byte.

(Originally filed as broken compressed-FS handling, but compression maps fine on current kernels — logical offsets/lengths with the ENCODED flag — the real trigger is the trailing hole.)

Fixes: #374