[LAPACK][cuSOLVER] Fix incorrect QR results on repeated runs (#626)

[zjin-lcf]

Summary

Fixes #626.

QR decomposition (geqrf + orgqr) on the cuSOLVER backend returned incorrect results on repeated runs: for a diagonal input matrix the diagonal of Q should be 1, but from the second run onwards (for n >= 256) some entries stayed at the input value 2. The corruption was nondeterministic and size-dependent, and did not occur on the Intel backends.

Root cause

The Householder-family cuSOLVER routines (geqrf, orgqr, ormqr, gebrd, orgbr, orgtr, ormtr, and the complex ung*/unm* variants) passed nullptr for cuSOLVER's devInfo argument and skipped the lapack_info_check call that every other routine (getrf, potrf, …) performs.

Beyond losing all error reporting, this also skipped the implicit synchronization that lapack_info_check performs: it reads devInfo back through a blocking queue.wait(). Without that wait, the SYCL event returned from the native-command submission could signal before the cuSOLVER kernels had actually finished, so the subsequent memcpy read partially-computed data — producing the observed run-2+ corruption.

Fix

• Allocate a real devInfo and call lapack_info_check in all of these routines (both buffer and USM paths), matching the established pattern used by the working routines. This restores error checking and removes the race.
• Align CusolverScopedContextHandler::get_stream with the cuBLAS backend by returning the interop handle's native queue (ih.get_native_queue()) instead of the queue's default stream.

Test plan — validated end-to-end on NVIDIA sm_103 device, CUDA 13.2

Built oneMath with -DENABLE_CUSOLVER_BACKEND=ON -DENABLE_CUBLAS_BACKEND=ON -DTARGET_DOMAINS=lapack using an open-source DPC++ toolchain (intel/llvm nightly, CUDA backend), and ran the #626 reproducer (QR of a diagonal matrix, checking Q diagonals across repeated runs):

Build	n=512, 6 runs
develop (unpatched)	FAIL — run 2+ have dozens of wrong diagonal entries
This PR	PASS — all runs, all diagonals == 1

Also verified n = 256, 512, 1024 all pass with the fix.

Attribution note for reviewers

I isolated the two changes on the device:

• devInfo / lapack_info_check change only (stream change reverted): PASS.
• get_stream change only (devInfo change reverted): FAIL — still races.

So the devInfo/lapack_info_check addition is what actually resolves #626 (via the synchronization it introduces and by matching the working routines). The get_stream change is included as a correctness/consistency alignment with the cuBLAS backend, not as the fix itself; happy to drop it if maintainers prefer a minimal change.

• End-to-end reproduce + fix (n=256/512/1024).
• devInfo/lapack_info_check counts balanced across buffer and USM paths.
• CI: cuSOLVER LAPACK functional tests.

Suggestion: add a functional test that runs geqrf+orgqr repeatedly on a known-diagonal matrix to guard against regressions.