DGX Spark: fix silent ARM codegen, add LlamaCppEx.RPC for two-node runs

[nyo16]

Brings up NVIDIA DGX Spark (GB10, aarch64, sm_121a) as a first-class target,
and adds the ggml RPC backend so one model can span two machines.

4 commits, 38 files, +5863/−70. Each commit builds and passes on its own, so
git bisect works.

Why this is not just a "new hardware" PR

The most valuable change here affects every aarch64 user, not just Spark
owners: ggml's CPU backend was being compiled at base ARMv8-A on an ARMv9.2
part, silently. GCC 13.3 predates Cortex-X925/A725 and rejects
-mcpu=cortex-x925, so ggml's -mcpu=native probe degraded to the base
architecture behind a soft CMake warning and a zero exit status.

objdump -d on the emitted libggml-cpu.a:

build	sdot	smmla	SVE
before (-mcpu=native)	0	0	none
after (-march=armv9.2-a+dotprod+i8mm+fp16+bf16+sve2)	1134	370	present

Those are the Q4/Q8 quantized matmul kernels — i.e. most of the CPU backend's
throughput was missing and nothing said so.

What's in it

1. Build correctness (5f790b2)

• LLAMA_CPU_ARM_ARCH names the CPU architecture instead of probing for it.
  Reaching it requires GGML_NATIVE=OFF, which drops ggml-cuda from one
  architecture to a 7-architecture fat binary, so LLAMA_CUDA_ARCH is now a
  hard $(error) when it's missing — a paired flag rather than a mysterious 6×
  build later.
• A flag change did not invalidate the build. Toggling a variable changes
  CXXFLAGS/LDFLAGS/CMAKE_FLAGS while touching no source file, so make kept
  stale objects, links and CMakeCache.txt. Surfaced as
  Function not found 'Elixir.LlamaCppEx.NIF':model_load/11.
• Every MIX_ENV shares one llama_cpp_ex_nif.so. Mix symlinks priv/ into
  each env's build tree, so dev/test/bench write one artifact while keeping
  separate objects. Building test with LLAMA_RPC=1 and bench without left
  whichever ran last in place, and the artifact's own timestamp looked current to
  the other env. Same hole let a downloaded precompiled artifact replace a source
  build. The link is now gated on a marker recording the config hash and a
  digest of the linked bytes.

2. LlamaCppEx.RPC (fd04df6) — opt-in via LLAMA_RPC=1. Without the flag
every entry point returns {:error, :rpc_unsupported} and a CPU/Metal build
compiles and loads unchanged.

3. Tooling, benchmarks, runbook (65ed68b) — scripts/spark/ (no sudo
anywhere), six benchmarks, and docs/dgx-spark.md as the one- or two-node
runbook.

4. Upstream defect checklist (0adec62) — three llama.cpp defects we work
around, recorded in the release guide's API-compatibility step with the command
that says whether each is still needed.

Results

model	prefill	decode
Qwen3-8B Q4_K_M	4331 t/s	40.5 t/s
Qwen3-30B-A3B Q4_K_M	3287 t/s	90.9 t/s

Three of four beat the published single-Spark references; the fourth is 7% under.

• Prefer MoE on this chip. Qwen3.6-35B-A3B has more total parameters than
  the dense 27B and decodes 5.5× faster — only ~3B are active per token and
  decode is bandwidth-bound.
• MTP pays on dense, not on sparse. 1.61× on Qwen3.6-27B dense
  (n_draft: 3), 1.03× on 35B-A3B. Speculative decoding spends compute to save
  bandwidth; an MoE has little bandwidth to save.
• Two nodes buy capacity, not speed. A model that fits on one node measures
  the same either way (pipeline parallelism is disabled whenever an RPC device
  participates). A model that does not fit is the entire argument: Qwen3-235B-A22B
  Q4_K_M (142.1 GB) runs at 13.7 t/s across the pair, versus a global OOM
  on one node that also killed an unrelated system service.
• RDMA is worth 11% of decode and 27% of prefill over TCP, and TCP is a
  survivable fallback.
• -sm tensor across two hosts runs, is correct, and is 2.7× slower. No prior
  report of this combination exists. The CUDA all-reduce bails to nullptr on any
  non-CUDA member, and the generic path degrades the RPC backend's absent 2-D
  tensor hooks into a loop of 1-D transfers. Use :layer.
• cpuidle tuning does nothing, one node or two, despite a 43× effect on ICMP.
  This retires the one recommendation that would have needed root.

Two negative results are kept on purpose.

Reviewer notes

The device-ordering trap is the easiest thing here to get wrong.
LlamaCppEx.devices/0 reports the ggml registry (RPC last); llama.cpp
rebuilds a different list for placement with RPC first. So gpu_index stops
indexing :tensor_split once a remote device is registered, and a backwards
split still produces correct tokens while benchmarking badly. That's why
:devices exists — used verbatim, no reordering — and why model_load went from
11 to 12 args across model.ex, nif.ex and llama_nif.cpp together.

Two upstream properties are documented rather than papered over:

• A peer failure kills the BEAM. RPC_STATUS_ASSERT is GGML_ABORT, so there
  is no error to catch. Registration is the one checkable step
  ({:error, :unreachable}); after that the VM is the unit of restart. Real
  isolation means a sidecar OS process — out of scope.
• RPC.Server.terminate/2 cannot stop the native server (upstream's accept loop
  is while (true) with no shutdown hook), so it's restart: :temporary and it
  traps exits so the warning actually reaches you on a supervised shutdown.

Verification

• macOS (Metal, no RPC): 421 passed, mix credo --strict clean, mix dialyzer
  0 errors, mix format --check-formatted clean, mix docs link-clean.
• DGX Spark (CUDA 13, LLAMA_RPC=1): 421 passed, 423 with --include rpc
  against a live two-node worker.

Known and deferred — a parallel review flagged 7 non-blocking warnings, none
on the shipped library path. The three worth picking up: orphaned cpuidle pollers
if a bench script dies mid-run; test/rpc_test.exs's @refusals set staying green
in exactly the stale-NIF case commit 1 prevents; and sync.sh having no models/
exclude.

The three upstream issues are drafted but not filed — docs/release-guide.md
has a slot for the URLs.