decmpfs 0.1.2 fails to compile on musl targets: FICLONE ioctl request typed c_ulong

clone_file in src/linux.rs (added in 0.1.2) declares the FICLONE request as libc::c_ulong:

// FICLONE = _IOW(0x94, 9, int) — stable since Linux 4.5.
const FICLONE: libc::c_ulong = 0x4004_9409;
let cloned = unsafe { libc::ioctl(dest_file.as_raw_fd(), FICLONE, src_file.as_raw_fd()) } == 0;

libc::ioctl's request parameter is libc::Ioctl, which is c_ulong on glibc but c_int on musl, so the crate fails to compile for every *-unknown-linux-musl target:

error[E0308]: mismatched types
    --> decmpfs-0.1.2/src/linux.rs:296:60
     |
 296 |   let cloned = unsafe { libc::ioctl(dest_file.as_raw_fd(), FICLONE, src_file.as_raw_fd()) } == 0;
     |                         -----------                        ^^^^^^^ expected `i32`, found `u64`
     |                         |
     |                         arguments to this function are incorrect
     |
note: function defined here
    --> libc-0.2.186/src/unix/linux_like/mod.rs:1731:20
     |
1731 |             pub fn ioctl(fd: c_int, request: Ioctl, ...) -> c_int;
error: could not compile `decmpfs` (lib) due to 1 previous error

Reproduce: cargo build --target x86_64-unknown-linux-musl (or aarch64-unknown-linux-musl) on 0.1.2. glibc, macOS, and Windows targets are unaffected.

Fix: cast at the call site, the way the other ioctls in the same file already do — libc::ioctl(dest_file.as_raw_fd(), FICLONE as _, src_file.as_raw_fd()) — or type the constant as libc::Ioctl. The comment above FS_IOC_GETFLAGS in that file already documents this exact hazard:

// `as _` at the call site casts it to whatever `libc::ioctl` expects per target
// (c_ulong on glibc, c_int on musl) — same 32 bits either way.

clone_file is the only ioctl call site in the file that omits the cast, so 0.1.0 built fine on musl and 0.1.2 does not. Still present on main at crates/decmpfs/src/linux.rs:295.

Context: this reached us as musl CI failures in jdx/aube after a lockfile bump to 0.1.2; we've pinned back to 0.1.0 for now. Happy to send a PR if that's useful.

This issue was generated by Claude.

Start in crates/decmpfs/src/linux.rs at clone_file and compare its FICLONE ioctl call with the other ioctl call sites and the FS_IOC_GETFLAGS comment. Reproduce with cargo build --target x86_64-unknown-linux-musl, then verify the crate builds for musl targets and that glibc, macOS, and Windows behavior remains unaffected.