perf(moe): wire mixtral to the fused decode-MoE kernel

[inureyes]

Summary

Group B migration for the fused decode-MoE kernel (#268 series, default-on since #282), chain 4/6 under epic #307 and sibling to #286 (qwen2_moe). mixtral's MoE experts move from its local SwitchGLU/SwitchLinear to the shared crate::models::switch_layers::SwitchGLU, and SparseMoeBlock::forward gains the single-token decode fused-kernel dispatch.

What changed

• src/models/switch_layers.rs: add SwitchGLU::from_weights_with_proj_names(weights, prefix, group_size, bits, [gate, up, down]). The default from_weights now delegates to it with the standard ["gate_proj", "up_proj", "down_proj"] names, so every existing shared caller (qwen2_moe, mistral4, dots1, kimi_linear, minimax, longcat) is byte-for-byte unchanged. The per-expert stacker already derives the expert leaf name from the projection segment of the prefix, so overriding the leaf names is all that is needed; no checkpoint-specific strings live in the shared loader. Doc comment on stack_individual_experts updated to note the override path; new unit test switch_glu_loads_overridden_proj_leaf_names exercises the w1/w2/w3 path.
• src/models/mixtral.rs: remove the local SwitchGLU/SwitchLinear (nothing else referenced them), point SparseMoeBlock.experts at the shared SwitchGLU, and load via from_weights_with_proj_names(.., "{prefix}.switch_mlp", .., ["w1", "w3", "w2"]) (gate=w1, up=w3, down=w2). SparseMoeBlock::forward now tries forward_fused_kernel for single-token decode when fused_moe_enabled(), falling back to experts.forward + moe_weighted_sum otherwise. mixtral uses softmax over the top-k logits with no shared expert and no renorm, so scores already carries the full combine weights; everything else in the forward path is unchanged.
• docs/benchmark_results/fused-moe-decode-kernel-design.md: move mixtral into the wired "Models covered" list and document the w1/w2/w3 mapping and the overridable-leaf-name loader.

Weight-loading parity

The old local loader read block_sparse_moe.experts.{idx}.{w1,w2,w3}.{weight,scales,biases} for idx ascending and stacked them along axis 0 with utils::stack_arrays, with gate_proj=w1, up_proj=w3, down_proj=w2. The shared per-expert stacker reads the same keys ({root}.experts.{idx}.{leaf} where the .switch_mlp virtual prefix resolves root to block_sparse_moe, identical to the qwen2_moe path), in the same ascending index order, and stacks along axis 0 with stack_owned. Both stackers reduce to the same ffi::stack(&ptrs, 0) call, so the resulting [num_experts, out, in_packed] tensors are identical. Bits: the local loader hard-set args.bits(); the shared loader infers per-tensor bits from (packed_in * 32) / (num_groups * group_size), which for Mixtral-8x7B-4bit (group_size 64) is (512*32)/(64*64) = 4 for w1/w3 and (1792*32)/(224*64) = 4 for w2, matching args.bits(). mode is affine (default), biases are present, so quantized_parts() is Some and the fused kernel qualifies.

Test plan

• cargo check --lib --tests --features metal,accelerate
• cargo clippy --lib --tests --features metal,accelerate -- -D warnings (clean; dead-code from the removed local structs would have failed -D warnings)
• cargo fmt -- --check
• Real-checkpoint validation pending the orchestrator on models/mixtral-8x7b-4bit: greedy temp-0 output coherent and byte-identical or within the documented f16 jitter class vs MLXCEL_FUSED_MOE=0, no NaN, no garbage; decode tok/s fused-on vs off recorded with no regression. A wrong w1/w2/w3 mapping or a bits/shape mismatch would surface as garbage decode here.

Closes #301

[inureyes]

Orchestrator validation + Dff guard (M1 Ultra)

Real-checkpoint validation on mlx-community/Mixtral-8x7B-Instruct-v0.1-4bit surfaced a regression: the fused decode kernel is ~21% slower than gather_qmm for mixtral (expert intermediate Dff=14336). The output is correct (coherent, w1/w2/w3 mapping verified), but the two-kernel fused path only wins while gather_qmm underutilizes the GPU (small experts); for large experts gather_qmm already saturates and the extra dispatch plus global-memory activation staging is a net loss.

To resolve this without regressing the small-expert winners, this PR adds a Dff upper-bound guard to forward_fused_kernel (MLXCEL_FUSED_MOE_MAX_DFF, default 4096; env-tunable since the break-even is hardware-dependent). The threshold was calibrated against measured break-even data:

Dff	model	fused vs gather_qmm
704	gemma4-26b-a4b	+13%
768	qwen3-30b-a3b / qwen3-vl-30b-a3b	+3.5% / +15.4%
1408	qwen2_moe / dots.llm1	+5.8%
1792	lfm2	+6.6%
2560	qwen3_next	+8.7%
6400	phi-3.5-moe	-5.9%
14336	mixtral	-21%

4096 keeps every measured winner (including qwen3_next at 2560) and excludes both losers (6400, 14336).

Validation with the guard:

• mixtral default (guard on): 51.8-52.5 tok/s == MLXCEL_FUSED_MOE=0 baseline 52.1 tok/s (falls back, no regression).
• mixtral MLXCEL_FUSED_MOE_MAX_DFF=99999: 41.2 tok/s (fused path re-arms, the -21% path returns, proving the guard is the gate).
• qwen2_moe (Dff 1408, below the bound): fused on 146.6 vs off 134.3 tok/s (still gains; guard does not disable small winners).

Net for mixtral: the local SwitchGLU/SwitchLinear migration to the shared struct removes duplication, and decode stays on the proven gather_qmm path.