Publish v0.0.9: Apache-2.0 license + integrator notes

[Barnadrot]

Summary

• Version: 0.1.0 → 0.0.9. Reserves 0.1.0 for the eventual Plonky3 upstream proposal after multi-platform validation (M2 Pro / M4 Pro / M4-M / Asahi / Hetzner).
• License: MIT OR Apache-2.0 → Apache-2.0. Single license, explicit patent grant — preferred for infrastructure crates that downstream provers will depend on.
• Add LICENSE file (canonical Apache 2.0 text, 202 lines from apache.org). Was declared in Cargo.toml but missing from disk; crates.io publish would lint without it.
• README: integrator-facing fixes — UB warning on phase-scoping contract, Platform support table, total-virtual-reservation note, license line corrected to Apache-2.0.
• Remove stray Air 0-byte file from repo root.

Why now

Published to crates.io: https://crates.io/crates/zk-alloc

Uploaded zk-alloc v0.0.9 to registry `crates-io`
Published zk-alloc v0.0.9 at registry `crates-io`

0.0.9 signals pre-stable so we can iterate the API freely before proposing 0.1.0 to Plonky3 upstream once the cross-platform validation lands.

What's in each commit

a409c13 — publish prep: license Apache-2.0, version 0.0.9, add LICENSE file

• Cargo.toml: version = "0.0.9", license = "Apache-2.0"
• New LICENSE (Apache 2.0 canonical text, 202 lines)

a8aa423 — publish prep: README license fix + integrator notes

Section	Change
License line	MIT → Apache-2.0 — see [LICENSE](LICENSE)
Phase-scoping contract	Added "Violating this contract is undefined behavior" — the old pointer becomes invalid the moment the next phase's first allocation overwrites the slab at the same offset
ZK_ALLOC_SLAB_GB row	Added total-virtual-reservation note: slab_gb × thread_count virtual (e.g., 8 × 16 = 128 GiB virtual). Physical RAM only consumed on touch.
Platform support table (NEW)	Linux x86_64 direct syscalls / Linux aarch64 direct syscalls with vm.overcommit_memory=1 requirement / Other Unix libc fallback (no NOHUGEPAGE) / Windows no-op stubs
Minimum RAM guidance	At least one slab per active thread when phases run; on memory-constrained machines (16 GiB M-series Macs) lower ZK_ALLOC_SLAB_GB or limit threads

Crate state after publish

• SPDX: Apache-2.0
• Platforms: Linux x86_64 + aarch64 (direct syscalls), macOS / *BSD (libc fallback), Windows (no-op stubs — use System directly)
• Default features: rayon-flush
• Dependencies (runtime): rayon ^1.10 (optional, default-on via rayon-flush), libc 0.2 (non-Linux only)
• Crates.io: indexed, downloadable

Test plan

• cargo publish --dry-run on Hetzner (Zen 4 Linux) — clean
• cargo publish from brain — succeeded, crate live on crates.io
• Tag v0.0.9 on main after merge + push
• Dispatch m4m-macos agent to: (a) verify Plonky3 feat/zk-alloc builds + runs, (b) switch from vendored zk-alloc/ workspace member → zk-alloc = "0.0.9" crates.io dep with p3_zk_alloc::* → zk_alloc::* import rewrites, (c) paired bench zk-alloc vs system allocator on prove flow, N=5

Not in this PR (follow-ups)

• aarch64 perf work (32 MiB-aligned mmap + MADV_HUGEPAGE + adaptive pre-touch) — on sync-from-leanmultisig-m2-2026-05-11 branch, ships as 0.0.10 or 0.1.0
• size-routing regression tests — on fix/safe-arena-routing branch, ships as next minor
• API freeze + 0.1.0 proposal to Plonky3 upstream — after all platforms validated