Windows Arc B580/G21: native CUTE attention forward hangs after PR #659

### Summary

After PR #659 was merged, the Windows Torch 2.13 CUTE sidecar builds and imports successfully for an Arc B580/G21 target, but every tested native CUTE attention forward hangs in a CPU busy wait. The equivalent PyTorch SDPA controls complete with finite output.

This issue tracks the unresolved G21/B580 runtime problem from my earlier PR comment:
https://github.com/intel/llm-scaler/pull/659#issuecomment-5494810071

### Environment

- GPU: Intel Arc B580 (G21), PCI ID `0xE20B`, `intel_gpu_bmg_g21`
- Driver: `32.0.101.8974`
- OS: Windows
- Python: `3.13.12`
- PyTorch: `2.13.0+xpu` (`torch.version.xpu == 20260000`)
- oneAPI compiler/ocloc: `2026.1`
- oneDNN: `3.11.2`
- sycl-tla: `2fc09973bfdf15755090fcb0e3b6ad236408a992`
- PR #659 head tested: `affc2ea6`
- Built wheel: `omni_xpu_kernel 0.2.0b2+torch213.bmg`
- Wheel SHA256: `4E35336F68E15FCCFB13A90B4F1FBFD9975DA6C946F9969A485F17994B7F68EE`

### Build detail

PR #659 hard-codes the Windows CUTE AOT target to `bmg-g31`. I made one isolated build-only change allowing `WINDOWS_CUTE_AOT_TARGETS["bmg"]` to be overridden and built with `bmg-g21`.

The resulting wheel imports successfully, and all of these report `True`:

- `cute.is_available()`
- `supports_d128_bhld()`
- `supports_minimax_h3_vae_d64()`
- `supports_sol_attn()`

### Reproduction results

PyTorch SDPA controls complete normally and return finite output. Native CUTE forward hangs for all tested layouts:

1. MiniMax H3 QKV-backed BF16, shape `[1, 56, 31, 128]`, Q/K stride `[7168, 128, 21504, 1]`: first attempt exceeded 124 seconds; repeat exceeded 34 seconds.
2. Dense BF16 BHLD `[1, 4, 31, 128]`: exceeded 34 seconds.
3. Legacy FP16 BLHD `[1, 256, 8, 128]`: exceeded 34 seconds.

Observed behavior:

- CPU busy wait; no Python exception and no explicit `DEVICE_LOST`.
- Process uses about 1.4 GiB RAM and must be terminated.
- Fresh Torch XPU device/matmul health checks pass after every terminated probe.
- I stopped before running Sol-Attn forward or the real H3 `[1, 56, 7461, 128]` gate.

### Device policy observation

`omni_xpu_kernel.device.info(0)` reports:

- `bmg_sku=unknown`
- `kernel_profile=generic-bmg`

The documentation describes generic BMG as the B70-compatible default. SYCL reports 5 slices x 4 subslices, and `ocloc ids bmg-g21` maps to `20.1.0`, so the scheduler-unit query is nonzero and the device image target appears consistent.

### Expected behavior

Either:

- the G21/B580 native CUTE forward completes and matches the finite PyTorch SDPA result, or
- the runtime rejects unsupported G21 hardware cleanly instead of advertising the capability and hanging.

### Questions

1. Is the Windows CUTE path expected to support G21/B580, or currently only G31/B70?
2. Should PCI ID `0xE20B` be classified with a G21/B60 policy rather than `generic-bmg`?
3. Is oneAPI 2026.0 required, or should 2026.1 work?
4. Is there a known-good small forward probe or G21 tile/policy override I should test?

I can provide the standalone minimal reproducer and test a targeted patch on the physical B580.