[lapack][cuSOLVER] Implement native LAPACK gaps

[zjin-lcf]

Summary

• implement trtrs (buffer and USM) with cublas<t>trsm, and return 0 from trtrs_scratchpad_size since trsm needs no scratchpad. trsm does not detect the exactly singular matrix that LAPACK reports through info, so the diagonal is searched for a zero before the solve is enqueued, which keeps the LAPACK behaviour of leaving b untouched and reporting the one based index of the first zero diagonal element (as a computation_error)
• implement the grouped (group_count/group_sizes) USM getri_batch with cublas<t>getriBatched, one native call per group, and grow the grouped getri_batch_scratchpad_size query so the out-of-place inverses of the whole batch fit
• support nrhs > 1 in potrs_batch (buffer strided, USM strided and USM grouped) by solving the columns of B one at a time with cusolverDn<t>potrsBatched, which only handles a single right-hand side
• report the info of every matrix of a batch through a new lapack_info_check_batch helper that throws lapack::batch_error, fix the USM get_cusolver_devinfo overload that copied a single int regardless of the batch size and did not wait on the asynchronous copy, and give the batched potrs solves a real (zero-initialised) info array instead of nullptr
• release the temporary device allocations of the strided and grouped potrs_batch, including on failure paths, instead of leaking them
• leave gerqf/ormrq/unmrq, hetrf and the m < n cases of gebrd/gesvd unimplemented because cuSOLVER and cuBLAS have no native equivalents

Implementation notes

• cublas<t>getriBatched requires a uniform n and lda within a call, so one call is issued per group. The oneMath 64-bit pivots are converted into a single 32-bit array holding n contiguous pivots per matrix, as expected by cuBLAS, and only the n x n part of each result is copied back from the scratchpad so that the lda padding of a is preserved.
• For potrs_batch, all right-hand side column pointer arrays are built and uploaded to the device before the first native call. When SYCL_EXT_ONEAPI_ENQUEUE_NATIVE_COMMAND is available the native calls are not synchronised, so rewriting a device pointer array between two calls would race with a call still reading it.
• cusolverDn<t>potrsBatched only writes its info array when a parameter is invalid, so the array is zero-initialised before the call.
• A unit diagonal is not referenced by trsm, so trtrs does not search it for zeros and stays fully asynchronous in that case.

Test plan

• Build the cuSOLVER LAPACK backend with DPC++ and CUDA 13.3.1 (cuSOLVER 12.2.6) on NVIDIA A100
• Run runtime dispatch LAPACK tests on NVIDIA GPU: 398 tests, 352 passed, 46 skipped, 0 failed (base commit: 320 passed, 78 skipped)
• Run compile-time dispatch LAPACK tests on NVIDIA GPU: 398 tests, 352 passed, 46 skipped, 0 failed (base commit: 320 passed, 78 skipped)
• Verify the 32 tests per dispatch mode that stopped being skipped: Trtrs accuracy and dependency, GetriBatchGroup accuracy and dependency, PotrsBatchGroup accuracy (nrhs = {9, 6}), PotrsBatchStride accuracy for both the buffer and the USM API
• Check the trtrs singularity path, which the test suite does not cover, with a standalone program: a zero third diagonal element gives computation_error with info() == 3 and leaves b unchanged, for both APIs and for real and complex types, while the same matrix with a unit diagonal solves normally
• Run clang-format 19.1.7 and git diff --check

Portability

The implementation only uses documented cuSOLVER and cuBLAS entry points together with basic SYCL kernels, and keeps the existing SYCL_EXT_ONEAPI_ENQUEUE_NATIVE_COMMAND code paths intact.

Left unimplemented

Routine	Reason
gerqf, ormrq, unmrq	neither cuSOLVER nor cuBLAS provides an RQ factorization; left unimplemented for rocSOLVER as well
hetrf	oneMath's hetrf is Hermitian, while cuSOLVER only offers the complex symmetric cusolverDn<C,Z>sytrf
gebrd, gesvd with m < n	pre-existing documented cuSOLVER limitations