Function adopt_runtime_fused 

pub fn adopt_runtime_fused(
    name: impl Into<String>,
    region: PatternNode,
    kernel: KernelRef,
    dtypes: Vec<DType>,
    backend: BackendId,
) -> Option<FusedOpId>

Adopt a synthesized/imported runtime fused op: register its recipe (the region) in the fuel-graph metadata sidecar and bind its kernel in the global binding table, then return the freshly-allocated runtime FusedOpId. After this the capability gate sees the op as fusable on backend, and the executor’s is_runtime arm resolves it dtype-precisely from the same table every static kernel lives in.

Takes the resolved parts (the region + the bound KernelRef), not a JitResponse — the JitResponse/SynthArtifact destructuring (+ the artifact-load step) happens at the seam-call site (jit_adopt), so the core dispatch layer stays free of the fuel-kernel-seam envelope crate. Returns None if the region is not registrable (non-decomposable / bad binds — surfaced by register_runtime_fused).

Idempotent under region dedup (2026-07-15). register_runtime_fused dedups structurally-identical regions to the SAME FusedOpId — so a second adopt_runtime_fused call for an already-adopted recipe returns the same id here too. Binding, however, is append-only (KernelBindingTable::register_full_with_source_generic): pushing the same KernelRef onto the same (id, dtypes, backend) key a second time would create a duplicate-identical sibling, which KernelBindingTable::finalize rejects (Error::Msg) — and the caller of finalize (extend_global_bindings’s .expect()) turns that Err into a panic while holding the global bindings write lock, poisoning it for every later caller.

Guard against this exactly at the idempotent-vs-genuinely-new boundary: before binding, check whether THIS kernel is already bound at (id, dtypes, backend) — the precise, dtypes-aware KernelBindingTable::lookup_alternatives view — and skip the bind if so. The check-then-bind runs inside a SINGLE extend_global_bindings write-lock critical section (not a separate read-lock check followed by a separate write-lock bind): two threads racing to adopt the same structurally-identical region + kernel + dtypes + backend (region dedup means unrelated call sites can land on the same id) would otherwise both observe “not yet bound” through a read-then-write race window and both bind, reproducing the duplicate-KernelRef panic anyway. A fresh id, or the same id with a different kernel / dtypes / backend, still binds exactly as before.