triton-kernels: fix Intel opt-flag heuristics copied from the NVIDIA path

[jiqing-feng]

Summary

opt_flags_intel.py was derived from opt_flags_nvidia.py but kept two
constants that encode NVIDIA hardware properties. Both are wrong for Xe and
together cost roughly an order of magnitude on Battlemage.

block_k. The NVIDIA helper derives block_k from the cacheline size; the
Intel copy hardcoded min(128, ...) instead. An Xe cacheline is half as wide,
so operand tiles were twice the size the hardware wants. Deriving it the same
way NVIDIA does needs the operand dtypes, hence the signature change.

num_warps. block_m * block_n // 4096 assumes a 32-lane warp. An Xe
sub-group is SIMD16, so a warp covers half as many elements and the same tile
needs twice as many to keep per-lane register pressure in range. A standalone
tl.dot sweep puts the optimum consistently at // 2048.

Also allows block_n as a tuning constraint, so the Intel path can be swept
from the outside like block_m and block_k already can.

Only the backend == "xpu" branch is touched; CUDA and HIP go through
make_default_opt_flags_nvidia / _amd and are unaffected.

Validation

bf16 on Intel Arc Pro B60, torch 2.13.0+xpu, one card:

shape	speedup
MoE, 4096 tokens / 32 experts / top4	~10x
MoE, 2048 tokens / 8 experts / top2	~9x
dense 4096³	~5x

Numerics are unchanged: max relative error against a float32 reference stays at
the same order as before, for both the dense and the MoE path.

For context, a hand-written Triton tl.dot matmul tops out around 3x the
post-fix throughput on this device and oneDNN around 9x, so a gap remains — but
it is in the Triton XPU backend, not in these heuristics.

Note

Benchmarking the MoE path against matmul_ogs_torch also needs the reference
implementation fix in the companion PR; the matmul_ogs path itself does not
depend on it.