Zero trimmed ranges under verifier flags to make Trim() observable

[llersch]

On Linux with ext4/xfs, fallocate(FALLOC_FL_PUNCH_HOLE | FALLOC_FL_KEEP_SIZE) causes reads from the punched range to return zeros, so Trim() is already observable there. On macOS, Windows, tmpfs, NFS, and filesystems that do not support PUNCH_HOLE, Trim() returns false and does nothing — meaning the trim path is effectively untested in most CI environments.

Under DUCKDB_RUN_SLOW_VERIFIERS or DUCKDB_ALTERNATIVE_VERIFY, explicitly zero the trimmed range with Write() before attempting fallocate. This makes Trim() observable everywhere: any code that reads a trimmed block will see zeros regardless of the underlying filesystem or OS.

The two flags are triggered independently and serve different purposes:

• DUCKDB_RUN_SLOW_VERIFIERS enables additive extra verification on top of the production code path. Zeroing fits here because it turns a silent no-op (on non-Linux or unsupporting filesystems) into a detectable operation without changing what the production path does.

• DUCKDB_ALTERNATIVE_VERIFY selects alternative implementations of the same operation. Zeroing is precisely an alternative implementation of trim: it achieves the same observable effect as PUNCH_HOLE (reads from trimmed blocks return zeros) through explicit writes rather than a kernel hole-punching syscall.

The two blocks are independent: on Linux with glibc >= 2.18, both the zeroing and the fallocate execute, exercising the production code path while still making the result observable.