perf(cuda,engine): extend batched-prefill trunk to dense GDN-hybrid + GPU-SLRU MoE paths (#114 follow-up)

[pekkah]

Follow-up to #110/#111/#114-B. The batched-prefill harness (PrefillBatchedCpuMoe → TrunkLayerBatched → GdnBlockBatched/AttnBlockBatched) is gated on _cpuMoe:

// CudaHybridGdnForwardPass.Prefill
if (BatchedPrefillEnabled && _cpuMoe && batchedSafe) { PrefillBatchedCpuMoe(...); }
else { for (i..N) Forward(tokens[i], startPos+i); }   // sequential per-token prefill

So two CUDA GDN-hybrid configurations still prefill sequentially per token and get neither the #111 GEMM-batched projections nor the #114-B fused GDN scan / batched-query SDPA:

1. Dense GDN-hybrid (!hp.IsMoE, e.g. Qwen3.6-27B-MTP) — _cpuMoe = false (constructor line ~809). Prefill is per-token Forward → GpuGdnBlockAt / GpuAttnBlockAt + per-layer CPU/GPU dense FFN.
2. GPU-SLRU MoE (_cpuMoe = false when SLRU capacity ≥ ~50% of experts, e.g. Qwen3-Coder-30B on CUDA) — same sequential prefill loop.

The trunk batching (#111 + #114-B) is independent of how the FFN/MoE runs — it only needs the per-token GDN/attn launches collapsed — so it should extend to both paths. The routed-MoE amortization (#110/#112/#114-A) is CPU-MoE-specific and would not apply to the SLRU path, but the trunk half would.

Scope

• Factor the trunk-batching path (TrunkLayerBatched + the host residual/norm/shared-expert plumbing) so it can drive a batched prefill for the dense and SLRU configs, with the FFN/MoE stage swapped per config (dense FFN batched à la CpuDenseFfn2 / on-GPU FFN; SLRU routed experts).
• Keep the _faulted non-transactional latch and the same bit-exactness contract.

Tests

• Extend BatchedPrefill_BitwiseMatchesSequential coverage to a dense GDN-hybrid model (27B-MTP) and a forced GPU-SLRU MoE config (SHARPI_CPU_MOE=0 on a model that fits SLRU), asserting bit-identical prefill logits vs the sequential loop.

Payoff

Prefill speedup for the 27B-MTP rows (sequential today) and the Coder-30B CUDA-SLRU row; quantify with bench-prefill.ps1 / bench-allrows-1k.ps1. (Vulkan and CPU-only GDN-hybrid backends would need their own batched kernels — out of scope here; track separately if wanted.)

[pekkah]

Resolved by #120 (merged to master, c35603a).

Factored TrunkBlockBatched (config-independent: norm → attn/GDN block → postBlock resid → post-attn norm, left on GPU) out of TrunkLayerBatched, and added PrefillBatchedTrunkGpuFfn — batched trunk + per-token GPU/CPU dense FFN or GPU-SLRU GpuMoeFfn. The trunk half (#111 GEMM-batched projections + #114-B fused sequential-scan + batched-query SDPA) now runs for the dense (!IsMoE) and GPU-SLRU (_cpuMoe==false) configs; the routed-MoE DRAM amortization stays CPU-MoE-specific (per the issue). Gated BatchedPrefillEnabled && BatchedTrunkEnabled && !_cpuGdn && !_cpuMoe && trunkBatchSafe.

Needed a new llm_matvec_q5k_gemm_n GEMM-N kernel — the batched GEMM-N previously handled only Q4_K/Q6_K/F32, but Q4_K_M GDN-hybrid trunks carry Q5_K projection weights.

Bit-identical to the sequential per-token Forward loop:

• dense: BatchedTrunkGpuFfn_BitwiseMatchesSequential_Dense27BMtp (incl. MTP draft logits), ..._MultiChunk_... (startPos>0 + EnsureStreamAll realloc), ..._SnapKvActive_... (per-position Q-capture branch)
• GPU-SLRU: BatchedTrunkGpuFfn_BitwiseMatchesSequential_GpuSlruMoe (35B-A3B forced SHARPI_CPU_MOE=0, 3670/10240 experts cached → real evictions)
• per-kernel MatMulBatched_Q5K_BitwiseMatchesSequential

Perf (27B-MTP CUDA, 4070 Ti, ~1K ctx): Q4_K prefill 6.3 → 8.3 t/s (+32%), Q5_K 4.2 → 5.4 t/s (+29%).

Note: Qwen3-Coder-30B (named in the issue) is a pure-attention MoE routed through CudaHybridForwardPass, not the all-GPU-trunk CudaHybridGdnForwardPass these changes live in, so it's unaffected — tracked separately. The FFN/MoE stage is still per-token (not batched) — also tracked as a follow-up.