Fix FP8 dequantization on MPS by falling back to CPU

[snwchd71]

Summary

MPS (Apple Silicon) does not support FP8 dtype conversion, causing dequantize_per_tensor_fp8() to crash with:

TypeError: Trying to convert Float8_e4m3fn to the MPS backend but it does not have support for that dtype.

This adds an explicit device + dtype guard to dequantize on CPU and transfer only the final result back to MPS. Includes a one-time logger.warning for visibility.

• No hot-path overhead: the check is a string compare + frozenset membership, only evaluated when the tensor is on MPS with an FP8 dtype
• Bit-identical results: every FP8 value is exactly representable in bfloat16/float16, verified with torch.equal
• Auto-disables: the dtype guard means this becomes a no-op if MPS ever gains FP8 support

Prior work

• Fix FP8 tensor support on MPS backend for Apple Silicon Macs #23 by @AoiYamada identified the same fix. This PR adds tests, a one-time warning, and the dtype guard.
• fix: CPU fallback for FP8 quantization on MPS (Apple Silicon) ComfyUI#12378 by @tashiscool fixes the complementary quantization path in ComfyUI core (stochastic_rounding, quant_ops.py). Both fixes are needed for end-to-end FP8 on MPS, confirmed by @vSnake87 on M3 Max.

Test plan

• test_dequantize_fp8_cpu_fallback_correctness — verifies fallback math is bit-identical to standard path (runs in CI, parametrized float16/bfloat16)
• test_dequantize_fp8_on_mps_device — end-to-end on actual MPS hardware (skipped in CI, parametrized float16/bfloat16)
• Full test suite: 103 passed, 203 skipped (CUDA/Triton), 0 failures
• ruff check clean