fix(syscall): MAP_NORESERVE on aarch64 Linux via raw syscall

[Barnadrot]

Summary

The raw-syscall path that issues MAP_NORESERVE was gated on target_arch = \"x86_64\" only. aarch64 Linux fell through to the libc::mmap fallback that omits the flag — fine for macOS (no equivalent flag exists there) but broken on Linux: with vm.overcommit_memory = 0 (default on Asahi Fedora and several other distros), the kernel's heuristic check rejects the multi-tens-of-GB arena reservation, mmap returns null, and ensure_region aborts the process before any allocation work happens.

This adds a parallel imp module gated on (target_os = \"linux\", target_arch = \"aarch64\") that mirrors the x86_64 raw-syscall path with the correct aarch64 ABI (svc 0, x8 = nr, x0..x5 = args) and syscall numbers (SYS_mmap = 222, SYS_madvise = 233). macOS path is unchanged.

Repro / verification

• Repro (pre-patch): cargo run --release -- xmss --n-signatures 100 --log-inv-rate 1 aborts with SIGABRT immediately after warming up.... Stack trace ends in zk_alloc::arena_alloc_cold → Once::call_once → std::process::abort (from ensure_region at lib.rs:166).
• Hardware: Apple M2 / Asahi Linux Fedora 42, aarch64, 16 KiB pages, 16 GiB RAM, kernel 6.14.2-401.asahi.fc42.aarch64+16k.
• Patched: all leanMultisig integration paths run cleanly. zk-alloc beats standard-alloc by +3.4% on the production XMSS 1550-sig workload (611 vs 591 XMSS/s, median over 3 runs).

Test plan

• cargo build --release succeeds on aarch64 Linux
• leanMultisig xmss --n-signatures 1550 runs end-to-end with patched zk-alloc
• zk-alloc beats standard-alloc on the same machine (+3.4%)
• Existing CI on x86_64 Linux still passes (path unchanged)
• macOS path still uses the libc::mmap fallback (no flag-set change)

🤖 Generated with Claude Code