sdk/rust: Fix overlayfs whiteout for base files in promoted dirs (#316)

When a base-layer file is unlinked or renamed inside a directory
that has been promoted from Base to Delta (via ensure_parent_dirs),
we correctly create a whiteout at the source path.

However, the deleted name could still reappear in listings:
post-unlink inode operations (e.g. utimens on a stale inode handle)
could copy the base file into delta, and readdir/readdir_plus only
applied whiteout filtering to base entries, not delta entries.

This caused failures like:
  - readdir still showing HEAD after unlink in promoted .git/
  - whiteouted base names being resurrected through delta merges

Fix by:

1. Applying whiteout filtering to delta entries in both readdir()
and readdir_plus(), so whiteouts are authoritative across the
merged overlay view.

2. Treating whiteouted paths as not found for inode-based operations:
getattr/readlink return no entry, and open/chmod/chown/utimens
return ENOENT semantics instead of copy-up.

3. Preserving existing promoted-parent whiteout behavior for unlink,
rmdir, and rename source paths.

Add/keep test coverage for promoted-parent unlink/rename and the
overlay readdir/unlink integration path under cli/tests.