fs-err 3.x fails to compile on target_os = "fuchsia" (chroot gated out)

[al8n]

Summary

fs-err v3.3.0 does not compile on target_os = "fuchsia". The chroot helper in src/os/unix.rs calls std::os::unix::fs::chroot unconditionally on Unix-family targets, but rustc's libstd gates that function out on Fuchsia.

Reproduction

cargo new --lib demo && cd demo
cargo add fs-err@3
rustup target add x86_64-unknown-fuchsia
cargo check --target x86_64-unknown-fuchsia

Result:

error[E0425]: cannot find function `chroot` in module `std::os::unix::fs`
  --> ~/.cargo/registry/src/index.crates.io-.../fs-err-3.3.0/src/os/unix.rs:56:28
   |
56 |         std::os::unix::fs::chroot(path).map_err(|err| Error::build(err, ErrorKind::Chroot, path))
   |                            ^^^^^^ not found in `std::os::unix::fs`
   |
note: found an item that was configured out
  --> library/std/src/os/unix/fs.rs:1187:8
   |
1186 | #[cfg(not(target_os = "fuchsia"))]
1187 | pub fn chroot<P: AsRef<Path>>(dir: P) -> io::Result<()> {

rustc 1.93.1 (stable). Fuchsia is cfg(unix) (it sets target_family = "unix"), so fs-err's Unix module is compiled, but std::os::unix::fs::chroot is not available there.

Suggested fix

Gate the chroot wrapper with #[cfg(not(target_os = "fuchsia"))] to mirror libstd:

// fs-err-3.3.0/src/os/unix.rs:53
#[cfg(rustc_1_56)]
#[cfg(not(target_os = "fuchsia"))]
pub fn chroot<P: AsRef<Path>>(path: P) -> io::Result<()> {
    let path = path.as_ref();
    std::os::unix::fs::chroot(path).map_err(|err| Error::build(err, ErrorKind::Chroot, path))
}

ErrorKind::Chroot can stay defined unconditionally; only the wrapper itself needs the gate. Same treatment should apply to fs-err 2.x if that branch also exposes chroot (I only verified v3).

Downstream context

This surfaces when a crate enables fs-err on Fuchsia. In my case it's fs4's optional fs-err3 / fs-err3-tokio features, which otherwise build on Fuchsia once the upstream gap is closed.

Happy to send a PR if the #[cfg(not(target_os = "fuchsia"))] approach is acceptable.