0.2.4: every rule brings its own environment

[Sunrisepeak]

What changes for a project

Before:

[build-dependencies.mcpp]
plugins = { version = "0.2.3", features = ["rules-cuda"], host-module = true }

[xlings.workspace]
"xim:cuda-nvcc"         = "12.9.86"
"xim:cuda-cudart"       = "12.9.79"
"xim:libcurand"         = "10.3.10.19"
"xim:cuda-cccl"         = "12.9.27"
"xim:libcuda-host-link" = { linux = "0.0.1" }

After:

[build-dependencies.mcpp]
plugins = { version = "0.2.4", features = ["rules-cuda"], host-module = true }

The second block was the rule's own knowledge, repeated by everyone who used
it — a copy that goes stale silently, because the rule moves and the projects
do not. Each rule now declares it, under the feature that selects the rule and
the accelerator it serves:

[target.'cfg(accelerator = "cuda")'.feature-xlings.rules-cuda]
"xim:cuda-nvcc"   = "12.9.86"
"xim:cuda-cudart" = "12.9.79"

Two gates, and both must open before a byte is downloaded. The feature says
whether the rule is wanted; the selector says whether this build compiles for
the device. A CPU-only build of the same project opens neither.

All five rules, with no exception. "Sometimes you have to supply it yourself"
is a rule nothing can state precisely enough to be useful.

The shape of each default is a judgement about coupling

Not a style. An exact version where the payload's version is coupled to
something the rule cannot see — a CUDA runtime must not be newer than the
driver it will meet, and the 12.9 line reaches every driver from r525 onward
where 13.x raises that to r580. A floor (>=) where no such coupling
exists: glslang, dpcpp, the CANN toolkit.

mcpp reads the difference. A bare version is a choice, so a project pinning a
different one wins and the override is reported; a >= is a requirement, so
a project pinning below it is refused naming both sides. Either way one version
is installed — which is what mcpp 2026.9.6.6 makes true, and why that is the
floor for every rule here.

Overriding is one line in the project:

[target.'cfg(accelerator = "cuda")'.xlings.workspace]
"xim:cuda-nvcc" = "13.3.33"

What is deliberately not moved

Anything the produced program chooses to run on. xim:mesa-lavapipe is a
device, and a rule declaring one would force a software renderer onto consumers
that have a GPU. The runtime adapters (compat:cuda-runtime,
compat:sycl-runtime, compat:vulkan-runtime) stay in the project for the
same reason and for a structural one: this package is reached through a
[build-dependencies] edge, so its own [dependencies] deliberately do not
reach the consumer's target.

Two fixtures were short by one accelerator

Raising the CI pin to 2026.9.6.6 turned hip-consumer red immediately: its
glob names accel = "hip, cuda12.9+{sm_89}" while [package] accelerators
listed only hip. sycl-consumer has the same shape, and so do mcpp's own
examples/09-heterogeneous/{hip,sycl}.

Neither CI could see it. mcpp skips those two examples in its example job, and
this repository's engine pin predated the check (2026.9.6.5). It took both
repositories moving.

Criteria

The four device fixtures now declare no payload at all and still build; that
alone does not distinguish "the rule declared it" from "the fixture still
does", so the new CI step asserts both halves:

• no [xlings.workspace] in the fixture's manifest — a property of a file this
  repository owns;
• mcpp's own report that the entries came from the graph pass rather than
  the root's (entries declared by dependencies).

That line only prints on a provisioning-stamp miss, and this job restores
~/.mcpp from a cache — so the step clears the stamp first. Without that, the
criterion's "no" and "this ran on a warm cache" are the same reading.

multi-rule-consumer keeps one override (xim:glslang pinned to the rule's own
floor) and the step asserts one version is installed, so the override path is on
the CI graph and not only in mcpp's e2e.