perf(moe): wire qwen3_next fused decode-MoE (qwen3.5/3.6) (#268 step 3a)

[inureyes]

Summary

Step 3a of #268: route qwen3_next's MoE decode through the fused single-token kernel, covering qwen3.5 / qwen3.6 (qwen3_5_moe) and qwen3_next itself. They went through a separate SparseMoeBlock/SwitchGLU copy that had no fused dispatch.

What changed

qwen3_next carries its own SwitchLinear/SwitchGLU (distinct from switch_layers and qwen3_moe). This adds:

• quantized_parts accessor on qwen3_next::SwitchLinear,
• forward_fused_kernel on qwen3_next::SwitchGLU (mirrors qwen3_moe),
• the fused dispatch in SparseMoeBlock::forward on single-token decode behind MLXCEL_FUSED_MOE.

Experts are 4-bit affine — fully supported by the existing kernel, no kernel change.

Result (qwen3.5-35b-a3b, M1 Ultra)

Decode 68.7 → 74.7 tok/s (+8.7%).

Correctness — within f16 jitter class (not byte-identical)

Unlike qwen3_moe/dots (byte-identical on the prompts tested), qwen3.5/3.6 greedy output is within the f16 jitter class, not bit-exact. The fused kernel accumulates the GEMV in f32 with a different reduction order than gather_qmm's tiling, perturbing the MoE block output by abs RMS ~1e-4 (max ~4e-4, both < 5e-3) — measured directly with temporary instrumentation. On a deep hybrid that is enough to flip a near-tie greedy token (~token 16 in tests); qwen3-30b happens not to hit one through 128 tokens. This is the design harness's documented "byte-identical or within f16 jitter class" allowance.

The rel_rms looks like ~1% only because the MoE block output is small-magnitude (~8e-3); the perturbation to the O(1) residual stream is ~1e-4, negligible.

cargo fmt/clippy clean. Off by default (MLXCEL_FUSED_MOE), single-token decode only.

Scope

gemma4-26b (its own Experts/gather_sort path) and nemotron-h (C++ fused_moe_forward) are separate MoE paths — follow-ups.

Refs #268.