fix(musa): keep torch.isfinite asynchronous on MUSA floating tensors

[yeahdongcn]

What / Why

On torch_musa 2.11.0.post2+musa5.2.0, every boolean mul blocks the host until the device queue drains. That covers boolbool, torch.mul, mul_ and boolscalar.

ATen computes isfinite of a floating tensor as (x == x) * (x.abs() != inf), so each torch.isfinite call on a MUSA tensor drains the queue too. With about 70 ms of GEMMs queued, isfinite blocked the host for 73-78 ms in float16, float32 and float64 alike. &, logical_and, integer mul and x.abs() < inf stayed asynchronous at 0.02-0.10 ms.

In vLLM-Omni's MAGI-2 Preview, the eager attention-sink correction calls isfinite once per attention layer, so every layer waited for the GPU to go idle.

Change

• For MUSA float16, bfloat16, float32 and float64 tensors, torch.isfinite and Tensor.isfinite return x.abs() < inf, the same predicate: False for NaN and for both infinities.
• Every other dtype and device keeps the original op:
  • integer and bool tensors are always finite;
  • a complex magnitude can overflow when both parts are finite;
  • fp8 types do not reliably implement abs and lt.
• The wrapper is registered as a TorchScript alias of aten::isfinite.
• torch.isfinite is added to the AOT autograd cache safelist, so compiled graphs that call it stay cacheable.
• There is no version gate, because the predicate is exact on every stack. The shim can be deleted once torch_musa's boolean mul stops synchronizing.
• Version 0.1.91.

Verification

tests/test_isfinite.py covers:

• values against CPU in f16/bf16/f32/f64, for NaN, ±inf, -0.0, a subnormal, ±finfo.max and finfo.tiny, on contiguous, transposed and strided views;
• 0-d and empty tensors;
• which inputs take the new path, checked with a spy:
  • MUSA f16/bf16/f32/f64 tensors through both torch.isfinite and Tensor.isfinite;
  • and not int32/int64/bool/complex64, nor CPU tensors;
• integer, bool and fp8 inputs returning the original op's result;
• no autograd tracking;
• work queued before the call still pending afterwards (checked with stream.query()), for f16/bf16/f32/f64 through both entry points. The test first asserts that the queue is busy, and skips under MUSA_LAUNCH_BLOCKING/CUDA_LAUNCH_BLOCKING;
• TorchScript;
• torch.compile(fullgraph=True) values and exactly one AOT autograd cache artifact, checked in a fresh interpreter.

On stock 0.1.90 all 8 queued-work cases (4 dtypes, 2 entry points) fail with "isfinite drained the device queue".

Results on MTT S5000:

• pytest tests/: 631 passed, 19 skipped, 2 failed. The two failures are in TestInductorTemplateHeuristics (KeyError: ('triton::bmm', 'musa', None) and the same for triton::mm) and fail the same way on 0.1.90 without this change.

End to end, on MAGI-2 Preview on 8x MTT S5000 (SP4xCFG2, 100 steps):

• on an earlier development tree, removing the stall cut a step from 2894 ms to 1137 ms;
• with an earlier revision of this change (same routing for those fp32 tensors) and the model unchanged, a step is no slower than with the model's two isfinite calls rewritten (the mean step time differs by under 1 ms);
• the generated video and audio are byte-identical (sha256) between the two.

Not covered / notes

• Code that branches on the result on the host, such as if not torch.isfinite(x).all():, still waits for the device, by design.
• TorchScript keeps calling aten::isfinite, so scripted code still takes the blocking path.
• The boolean mul synchronization itself is a torch_musa issue and should be fixed there; this shim only takes isfinite off that path.

AI assistance: Claude Code drafted the change, the tests and this description and ran the MUSA validation listed above. I reviewed every change in this PR and re-ran the validation listed above.