perf(turboquant): RHT-correct L=1 value kernels (keep the fast path under RHT)

[popfido]

Summary

Follow-up to #1244. That PR made the single-token (L=1) value Metal kernels correct under RHT by declining them — every RHT decode falls back to the slower einsum path. This PR makes the kernels themselves RHT-correct so the fast path stays engaged.

Root cause. _metal_mse_weighted_sum / _metal_mse_weighted_sum_from_scores / _metal_mse_weighted_sum_sum_from_scores return the weighted value sum in the codec's rotated space and undid it with a hard-coded matmul(weighted_rot, rotation). That inverse is only valid for the dense-rotation codec; under the Randomized Hadamard Transform (use_rht, the default for power-of-2 head dims) the correct inverse is _rht_inverse. The kernel computes weighted_rot correctly regardless of rotation type — only the post-kernel inverse was wrong, which is exactly why #1244 had to skip it.

Fix. Thread the codec's RHT signs into the three wrappers and apply the matching inverse through a small _value_rotate_inverse helper (_rht_inverse when signs are set, else the dense matmul) — mirroring _TurboQuantMSECodec._rotate_inverse and the already-correct fused-decode path (value_codec._rotate_inverse(out_rotated)). The not self.use_rht guards from #1244 are dropped so RHT decode takes the kernel again.

Prod-mode fused-decode call sites pass no signs (default None) → identical dense matmul, byte-for-byte unchanged.

Verification

New mlx_vlm/tests/test_turboquant_rht_value_kernels.py:

• Equivalence — kernel path vs einsum fallback vs dequantize ground truth across dims {64,128,256} × bits {2,3,4,8} × repeats {1,4}, plus the weighted_sum_stats_from_scores decode path. Agreement <1e-4 (kernel vs einsum) and <1e-3 (kernel vs dequant truth).
• Kernel-path guard — asserts RHT weighted_sum runs the Metal kernel and never the einsum fallback (which unpacks low-bit indices). This test fails on main today (RHT is skipped) and passes here.
• Existing test_turboquant.py suite: 23 passed, no regressions.

Benchmark (M-series, L=1 value reconstruction, dim=128 bits=4 B=4 H=8 repeats=4)

context T	einsum fallback	RHT kernel	speedup
512	1.85 ms	0.53 ms	3.5×
2048	3.05 ms	0.43 ms	7.0×
8192	15.56 ms	1.14 ms	13.7×

The gap grows with context length because the einsum fallback re-unpacks every token each decode step.

Scope / risk

Low. Kernel math is unchanged; only the post-kernel inverse moves to the RHT-aware _value_rotate_inverse. The dense-rotation and prod-mode paths are untouched (no signs → same matmul).

[Blaizzy]

LGTM, thanks!