merging #806 before this might be better. indirectly related (i.e., ArchSpecificProvider).

GPT-5.5 reported the following issues:

1. litebox/src/mm/exception_table.rs:101 — High: AArch64 inline asm uses label 10: / 10b, which can trigger Rust’s denied binary-asm-labels lint. Use a
   non-binary-looking label like 22: / 22b.
2. litebox_common_linux/src/lib.rs:907 — Medium: AArch64 suseconds_t is aliased to u64, but Linux defines it as signed long/i64. Negative tv_usec values
   can be misinterpreted. Use i64 and validate range explicitly.
3. litebox_common_linux/src/lib.rs:2584 — Medium: AArch64 disables legacy mkdir but does not decode mkdirat, so directory creation on AArch64 likely
   falls through to ENOSYS. Add a mkdirat decode path with the intended dirfd semantics.

GPT-5.5 reported the following issues:

1. litebox/src/mm/exception_table.rs:101 — High: AArch64 inline asm uses label 10: / 10b, which can trigger Rust’s denied binary-asm-labels lint. Use a
   non-binary-looking label like 22: / 22b.
2. litebox_common_linux/src/lib.rs:907 — Medium: AArch64 suseconds_t is aliased to u64, but Linux defines it as signed long/i64. Negative tv_usec values
   can be misinterpreted. Use i64 and validate range explicitly.
3. litebox_common_linux/src/lib.rs:2584 — Medium: AArch64 disables legacy mkdir but does not decode mkdirat, so directory creation on AArch64 likely
   falls through to ENOSYS. Add a mkdirat decode path with the intended dirfd semantics.

1. Interestingly, clippy for arm64 doesn't complain this. Anyway, let me change this.
2. Looks like both x86_64 and aarch64 use i64, so this might be a stale bug or known one (tv_usec shouldn't be negative even though it is a signed integer).
3. Let me change this once Add syscall mkdirat #898 is merged.

🤖 SemverChecks 🤖 No breaking API changes detected

Note: this does not mean API is unchanged, or even that there are no breaking changes; simply, none of the detections triggered.