[Bug]: held-tree rewalk test assumes a permissive umask

[FeathBow]

Summary

backend::held::tests::rewalk_rejects_add_remove_replace_and_mode_change fails on any machine whose umask already clears the bits its mode attack sets. The product behaves correctly; the test's attack is a no-op there, so the assertion that drift was detected fails.

Steps to reproduce

1. umask 0077
2. cargo test -p degu-core --lib rewalk_rejects_add_remove_replace_and_mode_change
3. Observe the failure on the Attack::Mode iteration.

Expected behavior

The mode attack changes the mode of a/b, and rewalk_structure reports drift.

Actual behavior

setup_tree creates a/b with std::fs::create_dir, so its mode is 0o777 & ~umask. Under umask 0077 that is already 0o700, and the attack's set_permissions(0o700) changes nothing. rewalk_structure() then correctly returns Ok, and the assertion at crates/degu-core/src/backend/held/tests.rs:2226 fails.

The other three attacks in the same loop — add, remove, replace — are unaffected, so the failure looks narrower than a rewalk regression would.

Environment

degu version: 0.1.7 (workspace, from source)
installation method: built from source
OS/kernel/architecture: x86_64 Linux
filesystem type: local ext4
byte or inode quota involved: no

Also reproduced on the same machine against an unmodified checkout, so it is not specific to any in-flight change. CI does not see it because its umask leaves the created mode different from 0o700.

Relevant output or logs

thread 'backend::held::tests::rewalk_rejects_add_remove_replace_and_mode_change' panicked at crates/degu-core/src/backend/held/tests.rs:2226:9:
assertion failed: tree.rewalk_structure().is_err()

Suggested direction

Give a/b an explicit mode in setup_tree, or choose an attack mode that cannot coincide with the created one, so the test states the mode it depends on instead of inheriting it from the caller's umask.