[MLAS] Fix Data Race in MlasLutGemm by Serializing LUT Generation

[tianleiwu]

Problem Description

The MatMulNBitsLutGemm.Float32_2Bits_Asymmetric_Batch32_256x256 test was exhibiting flaky behavior (failure rate ~2-20%) with numerical mismatches.
Investigation revealed a race condition in the GenerateLUT step within MlasLutGemm.

When the batch size M > 1, MlasLutGemm attempted to parallelize the LUT generation over the batch dimension using MlasTrySimpleParallel. However, the underlying GenerateLUT implementation (specifically shared usage of lut_scales/lut_biases or internal buffers) is not thread-safe for concurrent execution on the same destination buffers or related state. This led to corruption of the Look-Up Tables or scales, causing random output errors.

Solution

This PR modifies onnxruntime/core/mlas/lib/qlutgemm.cpp to serialize the GenerateLUT loop.
Instead of using MlasTrySimpleParallel, we now use a simple for loop to process each row of the batch sequentially.

Performance Impact:
The GenerateLUT step is computationally lightweight compared to the subsequent TMACComputeGemm matrix multiplication. Serializing this setup step has negligible impact on overall inference latency (micro-benchmarks showed no measurable regression), but effectively eliminates the race condition.

Verification

• Reproduction: The issue was reliably reproduced by running MatMulNBitsLutGemm.Float32_2Bits_Asymmetric_Batch32_256x256 in a loop (failing ~1 in 5 times).
• Verification: After applying the fix, the same test passed 50/50 iterations consistently.
• Regression Testing: Standard MatMulNBitsLutGemm tests (including BlkLen64 and M=1 cases) continue to pass.

[vraspar]

I ran two bit llama model and did not see any noticeable performance difference