[fixfon]

Part of #14705 (GNU test tests/shred/shred-remove)

Summary

When shred -u could not rename a file (for example because its directory is not writable), wipe_name printed "Couldn't rename to ..." and called std::process::exit(1). The file was never unlinked and the remaining operands were skipped, so shred -u shr/f ok/g with an unwritable shr left ok/g in place.

Now wipe_name stops renaming at the first failure and returns the last name that worked. do_remove then tries to unlink it, and the error is reported like GNU does: shred: shr/f: failed to remove: Permission denied. The run goes on with the next operand and still exits 1. The WipeSync path in the same function returns the I/O error instead of panicking on expect.

The failed to remove file message is now failed to remove (en-US and fr-FR) to match GNU. The shred-couldnt-rename string is no longer used, so I removed it. test_shred_fail_no_perm and the Linux-only /proc/self/mem test asserted the old rename message and are updated to the new output.

How I tested

New test test_shred_remove_in_unwritable_dir_keeps_going: a file in a read-only directory plus a second file. It checks the exact error, exit code 1, and that the second file is removed. It fails on main and passes now. It is skipped when running as root.

Run locally: cargo fmt --all -- --check, test_shred, cargo test -p uu_shred and cargo clippy --all-targets -- -D warnings. Tested on macOS (arm64), compared against GNU shred 9.12. The /proc/self/mem expectation is GNU 9.7 output on Linux.

[xtqqczze]

@fixfon Please open a specific issue for the work rather than referencing a tracker issue.