fix(pty): provide statx for musl builds

[jlongster]

Summary

• Linux musl builds have failed to link on every Release run since fix(pty): link Ghostty statically and add Windows CI #8 bumped Zig from 0.15.2 to 0.16.0: libghostty-vt.a: undefined reference to 'statx'. Zig 0.16's std.Io calls libc statx and assumes every musl provides it (std.c.versionCheck returns true for musl), but Rust 1.90's self-contained musl is 1.2.3; statx arrived in musl 1.2.5. This blocks the v0.2.0 release because the release job requires every build.
• Define statx for target_env = "musl" as a direct SYS_statx syscall, which is what musl 1.2.5's wrapper does (return value and errno semantics unchanged). Other targets are unaffected.

Validation

• Reproduced the CI failure in an ubuntu:22.04 aarch64 container with musl-tools, Rust 1.90.0, and Zig 0.16.0 through script/release-bin/zig.
• With the fix, every musl CI step passes there: cargo test --target aarch64-unknown-linux-musl --lib --test service --test ownership and --test playground, the release build, and the release smoke test (play --runtime-dir ... --name smoke).
• New musl-only unit test checks success on / and ENOENT for a missing path.
• cargo fmt --check and cargo clippy --all-targets -D warnings pass for aarch64-unknown-linux-musl, x86_64-unknown-linux-musl, and macOS.

Rollout

After merge, move the v0.2.0 tag to the merge commit to rerun the release.