Detached-parent create returns success for an unreachable file

One bug found by [Specula](https://github.com/specula-org/Specula):

Resolver::open(..., O_CREAT, ...) can retain an InMem directory handle after walking the parent, while a concurrent rmdir unlinks that parent from the namespace. InMem::create_file_at then inserts the new file into the detached directory and returns Ok(fd), so the caller receives a live file descriptor for a file with no reachable pathname.

Two operations race:

- Thread A resolves `/victim` and retains its `Arc`.
- Thread B removes `/victim` while it is empty.
- Thread A creates `child` through the retained `Arc`.

Both calls succeed, but `/victim/child` has no pathname because `/victim` is already detached.

**Expected Behavior**

Linux requires one of two outcomes:

1. Creation wins:
- `open(O_CREAT)` succeeds.
- `/victim/child` exists.
- `rmdir("/victim")` fails with `ENOTEMPTY`.

2. Removal wins:
- `rmdir("/victim")` succeeds.
- `open(O_CREAT)` fails with `ENOENT`.

They must not both succeed.

See the full [report](https://github.com/specula-org/specula-case-studies/blob/data/litebox-case-study-20260831/systems/litebox/modules/core/runs/litebox-known-aware-rerun-20260830/confirmed-bugs.md#entry-1-detached-parent-create-returns-success-for-an-unreachable-file) for more details.

Start by tracing Resolver::open(..., O_CREAT, ...) into InMem::create_file_at and inspect how the retained Arc interacts with concurrent rmdir. Use the two-operation race described in the issue as the first reproduction. Done means creation and removal are mutually exclusive: either the file remains reachable and rmdir returns ENOTEMPTY, or open returns ENOENT after removal.

Written by the indexing model from the issue text.