Function evaluate_effects 

pub async fn evaluate_effects(
    effects: &[Effect],
    bag: &mut AttributeBag,
    pdp: &Arc<dyn PdpResolver>,
    plugins: &Arc<dyn PluginInvoker>,
    delegations: &Arc<dyn DelegationInvoker>,
    elicitations: &Arc<dyn ElicitationInvoker>,
    phase: DispatchPhase,
    payload: &mut RoutePayload,
) -> StepsEvaluation

Walk an Effect list against the bag, dispatching PDP calls via pdp and plugin invocations via plugins. Returns the phase’s overall decision.

Semantics (DSL §3, §7.5):

• Effect::When — evaluate the condition; if true, run the body in order with the same first-deny-wins logic.
• Effect::Pdp — call resolver; on Allow run on_allow reactions and continue; on Deny run on_deny reactions and return the deny (reactions can override with their own deny, but cannot turn a deny into an allow).
• Effect::Plugin — invoke; Allow continues, Deny returns.
• Effect::Delegate — mint downstream credential; writes delegation.granted.* keys back into the bag; deny-on-failure unless the step’s on_error overrides.
• Effect::Taint — record the label; never halts.
• Effect::FieldOp — apply a pipe chain to args.X / result.X; may set args_modified / result_modified.
• Effect::Sequential — run children in order, halt on first Deny.
• Effect::Parallel — run children concurrently, abort on first Deny.
• Effect::Allow — explicit no-op; continues the phase.
• Effect::Deny — halt with the supplied reason/code.

PDP / plugin errors map to a Deny with the error in the reason, per the design’s fail-closed default (DSL §8.9). Pre-E4 evaluate_steps is preserved as a deprecated alias that forwards here.