[Bugfix][Dialect] Reject vector operands in atomic copy atoms

[AiyyappanMR]

Motivation

Passing a vector-typed value to an atomic-add copy atom currently generates illegal LLVM IR (llvm.atomicrmw fadd with a vector<Nxf32> operand), which is rejected by LLVM's IR verifier and, on AMDGPU, eventually surfaces as a cryptic unsupported cmpxchg failure deep in backend codegen with no useful diagnostic pointing back to the actual source of the problem (see issue #732, case 1). This PR adds a check that catches this earlier and reports it as a clear compile-time error instead.

Technical Details

UniversalAtomicAdd (and atomic copy atoms in general) only support scalar operands on this hardware — there's no native vectorized atomic-add instruction, and llvm.atomicrmw fadd only accepts a scalar floating-point operand, not a vector type.

Added a check in FlyUniversalOps.cpp that rejects a vector-typed operand being routed into an atomic copy atom, emitting: "vectorized atomic ops are unsupported; use a scalar-sized copy atom" instead of silently generating illegal IR that only fails much later during gpu-module-to-binary/backend codegen.

Test Plan

Reproduced the original crash using the example from issue #732 (case 1: sum_kernel with UniversalCopy128b load atom + UniversalAtomicAdd store atom, no retile). Confirmed the new check triggers a clear compile-time diagnostic instead of the previous downstream unsupported cmpxchg crash.

Test Result

Before: kernel compilation proceeded past MLIR lowering and failed with unsupported cmpxchg during gpu-module-to-binary, with no indication of the actual cause.
After: compilation fails immediately with a clear error pointing at the vector-operand/atomic-atom mismatch.

Submission Checklist

• Look over the contributing guidelines at https://github.com/ROCm/ROCm/blob/develop/CONTRIBUTING.md#pull-requests.