Function evaluate_contract_within 

pub async fn evaluate_contract_within(
    contract: &OutcomeContract,
    executor: &WorktreeExecutor,
    sink: &EventSink,
    deadline: Option<&SessionDeadline>,
) -> Vec<CheckResult>

evaluate_contract, bounded by a session deadline.

--max-session-wall-secs used to bound only the LOOP. The baseline run and the runtime’s own gate sat outside it, so total process wall time was baseline + wall_secs + gate, where the first and third terms were bounded only by the sum of the per-check timeout_secs a --contract-file supplies — with no cap on check count. Six checks at timeout_secs: 900 (a workspace-wide suite is not an exotic contract) could burn 90 minutes before the clock even started and another 90 after it stopped: roughly three hours for a run an orchestrator declared as ten minutes, and the orchestrator has no way to see it coming.

The deadline is consulted PER CHECK rather than once per evaluation, and that is what makes the bound real: a single snapshot clamp would give every one of six checks the same remaining budget and cap the total at six times it. Reading it as each check starts means the budget genuinely shrinks.

This does not interrupt a check already running — see super::budget on why mid-flight interruption is deliberately not how this works. It bounds what a check is ALLOWED to take, which is the part a caller can promise.