Intel XPU: all-black (NaN) output when Wan2.1-I2V-14B is combined with lightx2v step-distill LoRA — base model fine on XPU, same graph fine on CUDA

### Environment
- GPU: Intel Arc Pro B70 (32 GB), Linux, `torch 2.9.1+xpu`
- ComfyUI 0.25.0, Python 3.11 (venv), pytorch attention (sdpa)

### Summary
Using **Wan2.1-I2V-14B-480P** together with the **lightx2v step/cfg-distill LoRA** (`lightx2v_I2V_14B_480p_cfg_step_distill_rank64_bf16.safetensors`, applied via `LoraLoaderModelOnly`) produces a **fully black video** on Intel XPU. Latents appear to go NaN mid-sampling (KSampler preview shows a couple of steps, then turns black); every output frame has `signalstats YAVG=16`. **No error / traceback is raised.**

The identical graph **works on CUDA**, and the **same model without the LoRA works fine on XPU** (clean, coherent video), so the base Wan path on XPU is healthy — the failure is specific to the distill LoRA × XPU numerics.

### Repro (native nodes only)
`UNETLoader` (Wan2_1-I2V-14B-480P fp8_e4m3fn, Kijai repack, weight_dtype default) → `LoraLoaderModelOnly` (lightx2v rank64 bf16, strength 1.0) → `ModelSamplingSD3` (shift 5) → `KSampler` (4 steps, cfg 1.0, euler/simple) with `CLIPLoader` (umt5_xxl fp8 scaled, type=wan), `CLIPVisionEncode` (clip_vision_h) + `WanImageToVideo` (480x832, 33 frames) → `VAEDecode` (Wan2.1 VAE bf16) → video combine.

Any 480x832 portrait start image reproduces it.

### Elimination matrix (all tested on the same box)
| Stack | Config | Result |
|---|---|---|
| native ComfyUI | no LoRA, 20 steps, cfg 5 | ✅ good video |
| kijai WanVideoWrapper | no LoRA, 25 steps (fp8 & fp16) | ✅ good video |
| native ComfyUI | + lightx2v LoRA, 4 steps cfg 1.0 | ❌ black (NaN) |
| native ComfyUI | + lightx2v LoRA, 8 steps cfg 1.5 | ❌ black (NaN) |
| WanVideoWrapper | + lightx2v LoRA — fp8 / fp16 / bf16 + fp32 VAE | ❌ black (NaN) |

So it reproduces in **two independent implementations** (native nodes and WanVideoWrapper), at fp8/fp16/bf16 precisions, and is not affected by VAE precision, scheduler choice, or offloading (block swap disabled everywhere).

### Suspicion
Low-step / cfg=1 distilled sampling seems to push activations into a range where the XPU attention path (PyTorch SDPA fallback) overflows in half precision — similar in spirit to pytorch#119131 / #116176. Happy to run any diagnostics or file this against `intel/torch-xpu-ops` instead if that is the better home.

Reproduce the native-node graph using KSampler with the stated Wan2.1-I2V model and lightx2v LoRA, then compare the no-LoRA and CUDA controls. Start at the KSampler preview where values become NaN and inspect the PyTorch SDPA/XPU attention path. Done means the XPU graph produces non-NaN video while the existing controls remain successful.

Written by the indexing model from the issue text.