fix(runtime): validate routed-expert tensor shapes in Qwen GGUF loader

[RealDiligent]

Fixes #291.

Root cause

Qwen35Model::load_gguf validates the shape of every tensor it loads with expect_dims — attention, router (ffn_gate_inp), shared experts (ffn_*_shexp), and norms — except the three routed-expert tensors, which were loaded with only a null-check:

w.gate_q = dev_quant(b + "ffn_gate_exps.weight", w.gate_qtype);   // no expect_dims
w.up_q   = dev_quant(b + "ffn_up_exps.weight",   w.up_qtype);
w.down_q = dev_quant(b + "ffn_down_exps.weight", w.down_qtype);

These are the largest, fully file-controlled weights, and their per-expert stride (hidden × moe_ffn) is assumed — never re-derived — by launch_moe_expert_ffn_q4k (called with c.hidden / c.moe_ffn from the GGUF metadata). A GGUF whose expert_count / expert_feed_forward_length metadata disagrees with the actual tensor extent therefore loads cleanly, then the expert FFN computes offsets expert_id * hidden * moe_ffn with the wrong stride and reads out of bounds of the quantized blob → corrupt routed output or an illegal-address crash.

Fix

Add the missing expect_dims checks before the dev_quant loads, mirroring the existing ffn_*_shexp validation with the expert axis appended (ggml ne order):

tensor	expected dims
ffn_gate_exps.weight	{H, moe_ffn, n_experts}
ffn_up_exps.weight	{H, moe_ffn, n_experts}
ffn_down_exps.weight	{moe_ffn, H, n_experts}

A shape-mismatched GGUF is now rejected up front with a clear [gguf] bad shape … error, before any device pointer arithmetic runs.

Impact / risk

• Backward compatible. Valid Qwen3-MoE ({2048, 768, 128}) and Qwen3.6-35B-A3B ({2048, 512, 256}) GGUFs load unchanged — the expert tensors already carry exactly these extents (the runtime relies on them today).
• 10-line change, one file, host-side only; no kernel or ABI change.
• The dimension ordering was cross-checked against the sibling ffn_*_shexp checks in the same function, the transposes in runtime/tools/convert_gguf.py, and the standard llama.cpp MoE ne layout.

Verification

No GPU/CUDA build was available in this environment, so the dimension-ordering logic was verified by re-implementing expect_dims against the real tensor layouts:

• valid Qwen3.6 and Qwen3-30B expert shapes → accepted (models still load);
• wrong expert_count, wrong moe_ffn, transposed down axes, and 2-D rank → rejected before the kernel runs.

[skyrocket2026]

⏸ Merge conflict — rebase before eval

This branch conflicts with main, so the RTX 5090 eval is skipped until you rebase.

Please rebase onto main and push — the bot re-evaluates on the next poll once the PR is cleanly mergeable.

[skyrocket2026]

The round's merge-first PR was just merged. Please rebase this branch onto main — once you push the rebase the bot re-evaluates it against the new frontier (crediting your marginal gain on top of what merged).

[skyrocket2026]

The round's merge-first PR was just merged. Please rebase this branch onto main — once you push the rebase the bot re-evaluates it against the new frontier (crediting your marginal gain on top of what merged).

[skyrocket2026]

The round's merge-first PR was just merged. Please rebase this branch onto main — once you push the rebase the bot re-evaluates it against the new frontier (crediting your marginal gain on top of what merged).

[skyrocket2026]

The round's merge-first PR was just merged. Please rebase this branch onto main — once you push the rebase the bot re-evaluates it against the new frontier (crediting your marginal gain on top of what merged).