tests assume 4KiB filesystem allocation granularity

Several tests appear to assume a 4 KiB filesystem allocation granularity.
The commands themselves appear to behave correctly.

I encountered 11 test failures while running the test suite on AArch64 (Kernel: 6.19.14-400.asahi.fc42.aarch64+16k) with 16 KiB base pages.

The failing tests are:

failures:
    test_cp::test_cp_debug_default_with_hole
    test_cp::test_cp_debug_reflink_never_file_with_hole
    test_cp::test_cp_debug_reflink_never_sparse_always_with_hole
    test_cp::test_cp_debug_reflink_never_with_hole
    test_cp::test_cp_debug_sparse_never_file_with_hole
    test_du::test_du_symlink_multiple_fail
    test_ls::test_ls_block_size_override
    test_ls::test_ls_invalid_block_size_in_env_var
    test_ls::test_ls_long_total_size
    test_ls::test_posixly_correct_and_block_size_env_vars
    test_ls::test_posixly_correct_and_block_size_env_vars_with_k

The five cp tests for instance expect SEEK_HOLE sparse detection, but the fixture in this case is hardcoded to 10_000 bytes. When appending data it can create a visible hole on a 4 KiB filesystem but on a 16 KiB filesystem that offset is still within the first allocation unit. The other failing tests might be related as well.

Linux on AArch64 may use 4/16/64 KiB base pages. Filesystem allocation granularity can also differ independently of the CPU architecture.

Start with the listed test names, especially the five test_cp cases and their hardcoded 10_000-byte fixture, then run the affected tests on a 16 KiB filesystem. Check the related test_ls and test_du assumptions about allocation or block size; done means the tests pass without relying on 4 KiB filesystem granularity.