Every rule changes and no floor moves.

A rule used to take the whole of `mcpp::device_sources()`, which is the
PACKAGE's device set and not one rule's share of it. That is right for exactly
as long as a build has one rule in it, and the premise was never written down.
Measured with two rules in one build program:

    cuda:scale  clang -x cuda shaders/scale.comp -o scale.cu.o
    mcpp.rules.spirv: src/kernels/saxpy.cu has no shader stage.

Two failures, and the quieter one is worse: the CUDA rule did not refuse the
shader, it compiled it and produced an object.

Each rule now selects by extension -- `.cu`, `.hip`, `.sycl`, the shader stages
-- and a rule whose backend the build does not name returns without complaint,
which is what lets a build program call every rule it imports unconditionally
and `--no-accel` compile nothing.

No floor moves: none of that needs a newer engine. mcpp 2026.9.6.5 adds the
engine's half -- a device source that reached no action is refused, naming the
file -- but a rule package does not require it.

Verified by the package's own CI (green on main) with a new fixture,
tests/multi-rule-consumer: one package with a `.cu` and a `.comp`, both rules in
one build program, both products asserted, and `test ! -f scale.cu.o` for the
shader that must not have been compiled as CUDA. Run on a real device as well.

Both mirrors were downloaded and compared byte for byte before this descriptor
was written; one sha256 names both.