D2 — a non-dev register_toolchains propagates to every transitive consumer

rules_k8s refuses to register at all and defers to —extra_toolchains; rules_lean scopes its smoke toolchain with dev_dependency = True. Both are deliberate, and both are documented in prose in their MODULE.bazel. This makes that reasoning machine-checked.

The predicate is UNDECLARED leakage, not any registration: rules_jena legitimately registers four Jena toolchains because being a toolchain implementation is its entire purpose. Providers opt in via gate:toolchainProviderFor in declarations.ttl, which keeps the exception list reviewable as data rather than buried in a query.

An exemption comes in two strengths, and the difference matters:

• UNSCOPED — [] gate:toolchainProviderFor "rules_jena" . exempts every toolchain the module registers. Correct only when providing toolchains is the module’s entire purpose.
• SCOPED — the same, plus one gate:providesToolchain per label. Exempts only those labels; anything else the module registers is still a finding. This is what lets rules_lora be accountable for its three backend toolchains while its accidental @rust_toolchains//:all leak still shows up.

Both keyed on the module NAME, never a version IRI: an exemption says what a module IS, and republishing must not silently re-trip the gate.