🤖 SemverChecks 🤖 ⚠️ Potential breaking API changes detected ⚠️

--- failure struct_missing: pub struct removed or renamed ---

Description:
A publicly-visible struct cannot be imported by its prior path. A `pub use` may have been removed, or the struct itself may have been renamed or removed entirely.
        ref: https://doc.rust-lang.org/cargo/reference/semver.html#item-remove
       impl: https://github.com/obi1kenobi/cargo-semver-checks/tree/v0.48.0/src/lints/struct_missing.ron

Failed in:
  struct litebox::fs::devices::FileSystem, previously in file /home/runner/work/litebox/litebox/target/semver-checks/git-main/84f28ec743c369a9c8d81f9f732e00d61463d575/litebox/src/fs/devices.rs:68

GPT-5.5 found the following issues. You can decide if they should be addressed in this PR.

1. litebox/src/fs/resolver.rs:361-365 — High — O_CREAT | O_EXCL can run backend open side effects before failing.
   In the existing-file path, the resolver calls self.backend.open_file_at(outcome.last, name, flags)? before checking O_CREAT | O_EXCL and returning
   OpenError::AlreadyExists. Since open_file_at receives the full flags (litebox/src/fs/backend.rs:82-87) and O_TRUNC is accepted by the resolver
   (resolver.rs:292-304), a backend that honors open-time truncation could modify the file before exclusive-create failure is returned.
   Nuance: the only current Backend impl appears to be Devices, and its O_TRUNC handling does not mutate anything (devices.rs:270-277, 356-358). So this is
   a real generic resolver/contract bug, but likely not observable today with only the devices backend. The TODO at resolver.rs:361-362 explicitly confirms
   the intended fix.

2. litebox/src/fs/resolver.rs:329-336, litebox/src/fs/resolver.rs:348-355 — Medium — O_TRUNC is silently ignored for directories.
   The resolver opens root as a directory fd immediately at resolver.rs:329-336, and does the same for a resolved directory like /dev at
   resolver.rs:348-355. Neither branch checks O_TRUNC, even though O_TRUNC is accepted in the supported flags at resolver.rs:292-304.
   This is a behavior regression versus the existing in-memory filesystem: in_mem.rs:284-291 applies truncation after open, and in_mem.rs:436-448 returns
   TruncateError::IsDirectory when the fd is a directory. OpenError also explicitly supports TruncateError at errors.rs:29-30. So directory opens with
   O_TRUNC should not silently succeed unless that semantic change is intentional.

3. litebox/src/fs/resolver.rs:292-304, litebox/src/fs/resolver.rs:309, litebox/src/fs/resolver.rs:324, litebox/src/fs/resolver.rs:439-441,
   litebox/src/fs/resolver.rs:478-480, litebox/src/fs/resolver.rs:516-518, litebox/src/fs/resolver.rs:568-570, litebox/src/fs/resolver.rs:675-677 — Medium —
   Accepted O_PATH fds can panic on normal APIs.
   O_PATH is explicitly accepted by open at resolver.rs:292-304, recorded as path_only at resolver.rs:309, and stored in ResolverEntry at resolver.rs:324.
   Several fd operations then detect path_only and call unimplemented!, which panics instead of returning an error: read at resolver.rs:439-441, write at
   resolver.rs:478-480, seek at resolver.rs:516-518, truncate at resolver.rs:568-570, and read_dir at resolver.rs:675-677.
   Nuance: some calls may return an earlier error first depending on handle type or access mode, e.g. directory reads can return ReadError::NotAFile, and
   O_PATH without write access can return NotForWriting before reaching the panic. But valid O_PATH fds can still hit these unimplemented! paths, so
   accepting O_PATH while leaving these operations panicking is a real issue.

4. litebox/src/fs/devices.rs:138-143, litebox/src/fs/inode_allocator.rs:19-23, litebox/src/fs/inode_allocator.rs:38-44,
   litebox/src/fs/devices.rs:371-390 — Medium — / and /dev report the same inode.
   Devices::new allocates /dev with allocator.next() at devices.rs:138-143. InodeAllocator::for_device starts its counter at 0 (inode_allocator.rs:19-23),
   and next() returns the current counter before incrementing (inode_allocator.rs:38-44), so /dev gets inode 0.
   But root directory status also hard-codes ino: 0 while using the same dev as /dev at devices.rs:371-382. /dev status then returns self.dev_dir_inode at
   devices.rs:385-390. So stat("/") and stat("/dev") can both report the same (dev, ino).
   This is exposed through directory listing too: read_dir("/") reports the /dev entry using self.dev_dir_inode at devices.rs:285-291, while
   file_status("/")/file_status("/dev") go through resolver.rs:700-729 and surface the colliding dir_status values.

In prep for the next PR in the series, I've discovered that it may be helpful to slightly tweak the new Backend abstraction that this PR introduces. I don't think we should block merging this on that change, but just making a note that there may be a change to the Backend trait in a future PR if it leads to a simpler overall design (I still need to play around with the implications of the tweaked design I came up with this weekend, thus I don't want to tweak this PR just yet).