v0.23.9

fix(release): start ARM64 wheels on 64 KiB Grace systems (#427)

## Summary

- build ARM64 CUDA 13 wheels with a 64 KiB jemalloc page size
- parse NVIDIA's multi-ID closest-CPU NUMA output and keep allocation on
the first GPU-local CPU node
- bump the package version to `0.23.9`
- keep the allocator setting scoped to the ARM64 release jobs

## Motivation

The published ARM64 CUDA 13 wheel exits before CLI parsing on a 64
KiB-page Grace/GB300 host:

```text
<jemalloc>: Unsupported system page size
memory allocation of 4 bytes failed
```

The host reports `getconf PAGESIZE=65536`, while `tikv-jemalloc-sys`
otherwise derives its allocator page size from the 4 KiB GitHub runner
at build time. `JEMALLOC_SYS_WITH_LG_PAGE=16` makes the wheel compatible
with the target 64 KiB kernel-page environment.

On a 4×GB300 ARM64 host, recent NVIDIA tooling reports values such as
`NUMA IDs of closest CPU: 0,2-17`. The existing single-integer parser
treated every GPU mapping as unknown, then fell back to all 34 reported
NUMA nodes, including CPU-less nodes. Selecting the first
comma-delimited CPU node preserves the intended GPU-local allocation:
GPUs 0/1 use node 0 and GPUs 2/3 use node 1.

## Validation

- `cargo test -p pegaflow-common` (42 passed)
- `prek run --files pegaflow-common/src/numa.rs
.github/workflows/release.yml`
- CI checks passed, including Rust fmt/clippy, CUDA 12/13 cargo checks,
Python tests, and wheel builds
- manually dispatched ARM64 CUDA 13 release workflow built wheels for
Python 3.10-3.14: [run
31494259292](https://github.com/novitalabs/pegaflow/actions/runs/31494259292)
- installed the Python 3.12 artifact in a clean `uv` environment with
`torch==2.13.0+cu130` on an ARM64, 64 KiB-page, 4×GB300 host
- `pegaflow-server --help` passed, confirming the allocator initializes
on the 64 KiB host
- with the installed NVIDIA CUDA library directories on
`LD_LIBRARY_PATH`, the server started without `--disable-numa-affinity`,
selected exactly two GPU-local NUMA nodes, and served both `/health` and
`/metrics`