Blackwell dGPU bringup

[richiejp]

Continuation of RTX 5070 bringup. Presently there is a 6% regression in performance.

• spike(loader): rebase plain-BF16 direct loading
• feat(loader): transplant plain-BF16 Qwen3.5 loading
• docs(bench): activate local Qwen3.5-4B comparison
• bench: restore exact 4B corpus evidence
• bench: script exact Qwen3.5-4B comparison
• docs(bench): bind Qwen3.5-4B series root
• fix(bench): initialize 4B leg names safely
• docs(bench): bind corrected 4B retry root
• fix(cuda): restore discrete Blackwell memory classification
• docs(bench): record corrected Qwen3.5 4B comparison
• bench: void mismatched non-AOT comparison
• bench: record corrected 4B Triton AOT comparison

[richiejp]

• Packed recurrence: 2.585 s → 1.467 s (−43.25%)
• Fresh vLLM 0.25 comparison: 6418 vs 6744 tok/s (0.9517×), so overall parity remains open.

[localai-bot]

Merged to main as ee5e749..e7fd53b (rebased from merge-base a1611c7 onto a63c497 with git rebase --onto; no squash, authorship preserved on all 12 commits).

Conflicts: only .agents/parity-ledger.md and .agents/state.md, resolved as a union (main's Qwen3-Coder W5/W6 entries kept verbatim, Blackwell entries appended). The three files main rewrote the same day auto-merged with zero textual overlap, verified by inspection: main's bf16 grouped-MoE GEMM in cuda_matmul_nvfp4.cu and the per-layer ReleaseHost() fix in qwen3_5.cpp both survived intact. ENGINE_ROWS reconciled to 110.

Gates run on dgx GB10 (clean full rebuild, 121a, goldens md5-verified, final binary), which this PR had listed as PENDING:

Gate	Result
27B test_qwen27_paged_engine	235/235
35B test_qwen36_paged_engine	315/315
Qwen3-Coder test_qwen3coder_paged_engine	6/6 (max gap 0.0000 nats)
test_model_registry / test_cuda_backend / test_bench / test_qwen35_plain_weights	18/18, 5/5, 4/4, 3/3
compute-sanitizer memcheck (27B engine path)	0 errors
CUDA -Werror	0 warnings

test_cuda_backend logs pageable=1 integrated=1 UnifiedMemory=true on GB10, so the discrete-Blackwell classification fix is confirmed behavior-neutral on integrated hardware — it correctly stops a discrete Blackwell (which reports PageableMemoryAccess via HMM/UVM) from being handed the zero-copy DeviceScratch/KV/GDN contract.

On the 6.84%: a same-arch interleaved A/B of origin/main vs this branch on GB10 (27B NVFP4, 1024/128, c8, cold pair dropped) came out neutral to within ±0.15% on every axis against a ~0.3% spread — so there is no code regression reaching existing paths. That is also structural: DirectDeviceLoadEligible requires !is_unified_memory(), and the 35B/Coder are is_dense_model=false, so none of them enter the new branch.

Two caveats recorded rather than glossed:

1. The 120-vs-120a attribution is asserted, not measured. The stated argument ("local vLLM is 1.002x the previous reference, so the residual is project/build-side") doesn't carry — an unchanged vLLM arm shows the box is unchanged, not that our delta is build- rather than code-side. The direction is also counter-intuitive, since 120a compiles in more fast kernels. The mechanism is real and large enough (CMakeLists.txt:71,88,97,137,612 gate four kernel families on 12[01]a; FA2 alone measured +3.9% throughput / -36.4% TTFT on the 27B), but the owed experiment is a same-source 120-vs-120a A/B on the 5070 — dgx is sm_121 and has no 4B checkpoint, so it can't substitute.
2. test_qwen35_plain_weights passes, but its real-checkpoint leg skips here (Qwen/Qwen3.5-4B isn't on dgx), so the headline direct-device path is not exercised by our gates.

Merged on the basis that the gates are green and the 6.84% is scoped entirely to a newly-added path that has no main baseline it could regress. Thanks for the unusually rigorous benchmark record — voiding your own mismatched comparison rather than reporting it is the right instinct.