feat(examples): reach the driver through the index rather than an env var

The example previously needed LD_LIBRARY_PATH pointing at the xim sentinel,
because nothing declared a runtime search directory for the driver's userspace
library. compat.cuda-runtime now does, so the dependency is an ordinary one and
mcpp run works unaided.

The two packages divide the question by layer. libcuda-host-link in xim owns
where the host's copy is, so no consumer reimplements an ldconfig probe.
compat.cuda-runtime in mcpp-index owns how a built artifact reaches it, which
needs a directory on the runtime search path and is therefore something only an
mcpp package can declare.

Verified end to end on an RTX 4080: mcpp run prints 12 24 36 48 with no
environment variables set.

Author: speak-agent

examples/09-cuda-kernel/README.md

@@ -68,31 +68,34 @@ $ mcpp run
 
 which is `2.0 * [1,2,3,4] + [10,20,30,40]` computed on the device.
 
-## The one thing that is not closed yet
+## Where the driver comes from
 
 The CUDA runtime is linked statically, so the artifact carries every
 redistributable component. That leaves exactly one host dependency,
 `libcuda.so.1` — the driver's userspace library, which NVIDIA's licence forbids
 redistributing and which is in ABI lockstep with the kernel module.
 
-xim already has the right shape for this: `libcuda-host-link` is a sentinel
-package that installs a symlink to whatever the host has, so every GPU consumer
-reads one path instead of reimplementing an `ldconfig` probe. This example
-declares it under `[xlings] deps`.
+Reaching it takes two packages, one per layer.
 
-What is missing is the last hop. `[xlings] deps` provisions the payload and
-puts its `bin/` on `PATH`, which is what a payload providing a *program* needs.
-A payload providing a *library* also needs its `lib/` on the artifact's runtime
-search path, and mcpp's private loader does not consult `/usr/lib`, so without
-that hop the statically linked CUDA runtime cannot `dlopen` the driver and
-reports it as "driver version is insufficient". Until an mcpp-index package
-declares that directory, the run needs it supplied:
+`libcuda-host-link` in xim owns the question of *where* the host's copy is. It
+installs a symlink to whatever the machine has, so every GPU consumer reads one
+path instead of reimplementing an `ldconfig` probe.
+
+`compat.cuda-runtime` in mcpp-index owns the mcpp-side question of how a
+**built artifact** reaches it. mcpp's private loader does not consult
+`/usr/lib`, so a bare-soname `dlopen` from inside a built program finds nothing;
+the package declares a directory on the artifact's runtime search path and links
+through the sentinel. It is declared here as an ordinary dependency:
+
+```toml
+[dependencies.compat]
+cuda-runtime = "2026.09.05"
+```
+
+Without it the program builds and links, then reports
 
 ```
-$ LD_LIBRARY_PATH=$(xlings pkginfo libcuda-host-link)/lib mcpp run
+cudaMalloc: CUDA driver version is insufficient for CUDA runtime version
 ```
 
-This is an ecosystem gap, not a defect in the design: the durable fix is a
-`compat.cuda-driver` package in mcpp-index that wraps the sentinel and declares
-its library directory, which is the same shape every other runtime provider in
-that index already has.
+which is what the runtime says when it cannot open the driver at all.

examples/09-cuda-kernel/app/mcpp.toml

@@ -13,6 +13,13 @@ import_std = true
 [dependencies]
 rules-cuda = { path = "../rules-cuda", host-module = true }
 
+# The driver's userspace library, reached through an index package that owns
+# the one hop mcpp needs: a directory on the artifact's runtime search path.
+# mcpp's private loader does not consult /usr/lib, so without it the statically
+# linked CUDA runtime cannot dlopen the driver.
+[dependencies.compat]
+cuda-runtime = "2026.09.05"
+
 # The driver's userspace library, reached through the sentinel package.
 #
 # It is the one CUDA component that cannot be an ordinary payload: NVIDIA's