fix(cow): return ENOENT when opening a file deleted in the branch

[dzerik]

Problem

A file deleted in a seccomp COW branch is recorded as a whiteout in the in-memory deleted set; the real lower file is intentionally left untouched until commit. The stat/access handlers honor that whiteout and return ENOENT, but the read/open path did not: for a deleted path opened without O_CREAT, prepare_open returned CowOpenPlan::Skip, which handle_cow_open maps to NotifAction::Continue — so the kernel opened the untouched lower file and the reader saw the file's pre-delete content.

The two paths disagreed, so a deletion was invisible to a reader.

Example

# workdir/secret.txt exists with content "PREDELETE", COW active
rm -f secret.txt
test -e secret.txt        # -> false   (stat path: ENOENT, correct)
dd if=secret.txt of=out   # -> succeeds, out == "PREDELETE"  (open path: leaks lower bytes)

cat secret.txt happens to hide the bug because coreutils cat stats first and short-circuits on the (correct) stat ENOENT; a bare open() with no preceding stat (dd, a raw openat, some readers) hits the leaking path.

Fix

Add CowOpenPlan::Deleted for a whiteout opened without O_CREAT; handle_cow_open maps it to NotifAction::Errno(libc::ENOENT), matching the stat/access handlers. Reads of a deleted file now fail closed instead of leaking lower content.

Tests

• Unit: prepare_open reports Deleted (not Skip) for a whiteout opened O_RDONLY.
• Integration: a child deletes a workdir file, then a bare open (dd) must be denied (ENOENT) and copy zero bytes — the test fails with leaked: "PREDELETE" on the old behavior.

Scope

This is a general COW whiteout fix on the read/open path — it also reproduces in a single (non-pipeline) sandbox. It additionally makes a stage's deletion visible to later stages under the read-committed model of the multi-sandbox transactions work (#65), which is why I split it out as its own small change.

[congwang-mk]

Thanks for the PR! Two issues in the same bug class, one per inline comment.

[congwang-mk]

This fixes the seccomp dispatcher, but chroot mode still leaks: the sync handle_open above (~line 385) returns Ok(None) for a whiteout without O_CREAT, and chroot/dispatch.rs maps Ok(None) to a fall-through that opens the real lower file via openat2_in_root, so a reader still gets the pre-delete bytes there. handle_open should surface the whiteout too, with the chroot call site mapping it to ENOENT.

[congwang-mk]

O_CREAT on a whiteout bypasses the fail-closed guarantee this PR adds: prepare_copy removes the path from deleted and copies the lower bytes into upper, so rm f; touch f; cat f (or a bare open(f, O_CREAT|O_RDONLY)) resurrects the pre-delete content. After unlink, O_CREAT should create an empty upper file instead of copying lower. Fine as a tracked follow-up if out of scope here.