Module capability 

Unified capability decision boundary across evaluator backends.

Every backend asks the same question before dispatching a guarded native fn: does the host grant the bit this fn declared? CapabilityGate is that single decision; the backends differ only in when they consult it:

• Tree-walker — at dispatch time, on every native-fn call site (check_native_fn_capability delegates straight to the gate).
• Cranelift-native — at vtable-build time (once per run_main): CapabilityVtable::register_via_gate consults the gate so a denied bit is materialised as a null slot, and the in-IR cap_lookup + null-check then traps on a denied call.
• Bytecode VM — at dispatch time, via the per-call-site consult_gate consult before any guarded op touches the stack.

A denial surfaces as RuntimeError::CapabilityDenied across all three (the compiled backends carry only the numeric cap_bit; the tree-walker also fills a human-readable reason).

Hosts that need a custom policy (e.g. trust-level thresholding, per-call audit logging) implement CapabilityGate and wire it anywhere the default Capabilities-driven gate is used today.

Traits

CapabilityGate

Single source of capability-policy truth for evaluator backends.