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

[zjin-lcf]

Follow-up to #748: the same #626 failure happens on the rocSOLVER backend, and this PR fixes it there.

Stacked on #748 — it is branched off that PR's head, so until #748 merges the diff here also contains its commits. The rocSOLVER-specific work is the last three commits.

The failure on ROCm

The geqrf + orgqr diagonal regression test added in #748 is backend agnostic, and it fails out of the box on an AMD Instinct MI100 (gfx908, ROCm 7.1.1), with exactly the #626 symptom — for a diagonal input the diagonal of Q stays at the input value on some runs:

[3]: 1024 1024 6 # FAIL
        run 5: Q(863, 863) = 2, expected 1

Root cause

rocSOLVER calls only enqueue work on the HIP stream of the surrounding host task / native command. When ext_codeplay_enqueue_native_command is available, this backend skips the hipStreamSynchronize it otherwise performs, so the call returns with the factorization still in flight.

That is only safe if a dependent submission is ordered against that stream, and it is not: urEnqueueNativeCommandExp picks the stream through getNextComputeStream(NumEventsInWaitList, EventWaitList, Guard), which merely tries to reuse the stream of a dependency and enqueues no hipStreamWaitEvent for the wait list. When the heuristic declines, orgqr runs on a second stream that never waits for geqrf.

Unlike getrf/potrf/..., the Householder routines have no info output in rocSOLVER, so they also do not get the implicit host-side wait that lapack_info_check performs — which is what makes the cuSOLVER fix in #748 work. There is no equivalent argument to pass here.

Reduced to plain SYCL + rocSOLVER (no oneMath), on the MI100:

variant	wrong results
two dependent native commands, relying on the SYCL event dependency	5/15 runs
same, plus an explicit hipStreamWaitEvent between them	0/15 runs
same, on an in-order queue (single stream)	0/10 runs

The same reduction with plain hipMemsetAsync instead of rocSOLVER does not fail, because a single stream is used often enough for the heuristic to hold.

Changes

• Wait for the stream before returning from a rocSOLVER call. This is what the backend already did on toolchains without ext_codeplay_enqueue_native_command; the unsynchronized path is dropped rather than kept for a case where it is not sound. Fixing the ordering in the UR HIP adapter (both it and the CUDA one look affected) would let this be relaxed again.
• Take the HIP stream from the interop handle, as [LAPACK][cuSOLVER] Fix incorrect QR results on repeated runs (#626) #748 does for cuSOLVER. Both spellings resolve to the same stream inside a native command today, so this is an alignment with the other backends, not the fix.
• Check the devInfo allocation, mirroring the create_devinfo helper [LAPACK][cuSOLVER] Fix incorrect QR results on repeated runs (#626) #748 adds to cuSOLVER.

Test plan — AMD Instinct MI100, ROCm 7.1.1, oneMath built with -DENABLE_ROCSOLVER_BACKEND=ON -DTARGET_DOMAINS=lapack and an open-source DPC++ (intel/llvm, HIP backend)

geqrf + orgqr regression test from #748, n = 256 / 512 / 1024, 6 runs each, buffer and USM, RT and CT APIs:

build	result
#748 head, unpatched	FAIL — 3 of 4 test cases, from run 0 to run 5 depending on the run
this PR	PASS — 4 of 4, repeated invocations

Full LAPACK suite against Netlib reference (ILP64 LAPACKE), run one suite per process, unpatched vs. patched:

• 172 passed with this PR vs. 169 unpatched; the difference is exactly the QR regression tests.

• 112 failures remain, all in the *BatchGroup suites, which throw unimplemented for the group-batch APIs. Identical on the unpatched build.

• Getrf/Getrs USM abort in both builds inside the DPC++ runtime (ProgramManager::getDeviceKernelInfo assertion) before reaching any oneMath code; unrelated to this change.

• Reproduced [cuSOLVER] Incorrect results in QR decomposition on CUDA #626 on ROCm and confirmed the fix.

• No change in the rest of the rocSOLVER LAPACK suite.

• CI: rocSOLVER LAPACK functional tests.

The rocBLAS, cuBLAS and cuSOLVER backends share the same #ifdef SYCL_EXT_ONEAPI_ENQUEUE_NATIVE_COMMAND pattern and are exposed to the same hazard; I have left them alone here.