compat.sycl-runtime 2026.09.07: the adapter carries the driver hop

[Sunrisepeak]

2026.09.06 farms the SYCL runtime and its dlopen chain, and a SYCL artifact
using the CUDA back end still needed compat:cuda-runtime declared beside it,
because libur_adapter_cuda.so.0 reaches libcuda.so.1 through the artifact's
own search path. That is a true statement about the implementation and a poor
one to put in a user's manifest: which back end the SYCL runtime dlopens is the
runtime's business, not the project's.

2026.09.07 declares xim:libcuda-host-link and links the same versioned soname
compat.cuda-runtime links -- the same sentinel, the same file, the same
soname, so a program that has both farms on its path loads it once. Only the
versioned name: mcpp puts runtime.library_dirs on the LINK line as well, and
an unversioned libcuda.so would be found by -lcuda and bind the build to
one machine's driver.

Nothing is required of the machine. On one with no NVIDIA driver the sentinel
installs a deliberately dangling link and warns, and the SYCL runtime reports
its CUDA back end unavailable -- which is the correct answer and the one it
would give anyway.

Measured: a consumer declaring compat:sycl-runtime = "2026.09.07" and NOTHING
else from compat, with xim:dpcpp, xim:gcc and xim:cuda-nvcc in its
workspace, answers 12 24 36 48 on an RTX 4080.

2026.09.06 is kept and frozen; a consumer already pinning it keeps resolving
and installs the farm it always did.