perf(moe): record CUDA fused-MoE Dff cap provenance and decline test

[inureyes]

Summary

Complete the backend-aware fused-MoE Dff cap for #330 by recording the honest provenance of the CUDA default and pinning the decline boundary with a test. The cap-resolution logic itself (Metal 4096 / CUDA 8192, the MLXCEL_FUSED_MOE_MAX_DFF override, the pure fused_moe_max_dff_from, and the 2026-07-03 GB10 sweep) already landed in #643; that work was measured under MLX pin e9463bb (#626) and was never linked to #330. Since #643 the MLX pin advanced to 0.32.1 (#703/#704, commit 57c66cac), so the CUDA default is now a carried-forward documented-data value, not one confirmed on current binaries. This PR closes that honesty gap, documents the runtime-vs-cfg! backend choice, adds a decline-boundary test, and formally closes #330. The cap value 8192 is unchanged.

What changed

• src/models/switch_layers.rs: expanded the FUSED_MOE_MAX_DFF_CUDA doc comment with a provenance caveat (the 8192 sweep ran on MLX pin e9463bb/perf(cuda/moe): backend-specific default for the fused decode-MoE Dff threshold #626; the pin has since moved to 0.32.1/chore(mlx): bump upstream MLX pin to 0.32.1 #703/chore: bump MLX pin to 0.32.1 (#703) #704, commit 57c66cac; 8192 is the conservative crossover floor kept so pin drift cannot flip it into a regression; a GB10 re-validation on 0.32.1 is pending).
• src/models/switch_layers.rs: documented on fused_moe_max_dff_from that the cap is family-agnostic (governs every SwitchGLU MoE model per the module Used by: list) and that the backend is resolved at runtime via metal_is_available() rather than a cfg!(feature = "cuda") switch, matching the fused kernel's own runtime dispatch (run_fused_moe_two_kernel picks the cuda_kernel port when metal::is_available() is false).
• src/models/switch_layers.rs: added fused_moe_dff_above_cap_declines_and_at_cap_dispatches, a pure test pinning that forward_fused_kernel declines exactly when dff > max_dff at the cap boundary on both backends and under an explicit override.
• docs/benchmark_results/fused-moe-decode-kernel-design.md: added the 2026-07-09 addendum (CUDA default provenance, why keeping 8192 is safe under pin drift, and the pending GB10 re-validation on MLX 0.32.1 with the exact mlxcel-bench-decode harness to run it), and cross-referenced it from the MLXCEL_FUSED_MOE_MAX_DFF table row.

Design notes

• The value 8192 is unchanged. Under pin drift the most conservative floor of the measured crossover (break-even at 8192, regression only at 14336) is the correct choice, so no re-tuning is done without hardware re-validation.
• Metal behavior is byte-identical by construction (still 4096). The diff is runtime-inert (doc comments, a doc file, and a test only); no compiled non-test code path changed.

Test plan

Ran here (Apple M1 Ultra, Metal):

• cargo fmt --all -- --check
• cargo test --release --features metal,accelerate -p mlxcel --lib switch_layers (8/8 pass, including the new fused_moe_dff_above_cap_declines_and_at_cap_dispatches; the successful release build subsumes cargo check --lib --tests)
• cargo clippy --features metal,accelerate -p mlxcel --lib --tests -- -D warnings (clean)
• Metal MoE decode smoke, dispatch unchanged: mlxcel generate -m models/qwen1.5-moe-a2.7b-4bit -p "Hello" -n 32 --temp 0 produced coherent output at 96.58 tok/s on Apple GPU (Metal), exercising the fused MoE decode path (Dff below the 4096 Metal cap, so it dispatches).

Documented-data (not re-run in this PR): the CUDA default 8192 rests on the GB10 sweep in the 2026-07-03 addendum under MLX pin e9463bb (#626), landed in #643.

Pending (hardware-blocked): GB10 re-validation of the crossover on the current MLX 0.32.1 pin. No CUDA/GB10 hardware was reachable for this change; the how-to-run harness is recorded in the 2026-07-09 addendum.

Closes #330