feat!: require create_job's context to cover the template's extensions

[mwiebe]

What was the problem/requirement? (What/Why)

Background: templates are validated against a ValidationContext —
the spec revision, the enabled extensions (like EXPR, the expression
language), and any caller limits. create_job takes the same context
when it instantiates a job from a validated template. Since #404 it
also re-checks the template's carried-forward strings (action
command/args, environment variables, embedded-file data) with
the real parameter values bound, catching value-dependent failures at
submission instead of on every worker.

create_job documented that passing a context whose extensions
differ from what the template declares is supported policy — e.g.
"strip EXPR even if the template requests it". That one allowance
poisoned the new checks: with a mismatched context, an evaluation
error could mean either "the template is broken" or "the context
turned a feature off", so the checks had to silently skip all
evaluation errors except budget exceedances. Silent skips are
unobservable — a field that errored looks identical to a field that
passed — and the special-casing this required was itself buggy.

What was the solution? (How)

Remove the allowance and enforce the coherent contract: the context's
revision must match the template's, and its extensions must cover
everything the template declares (more is fine; fewer is a
Compatibility error). An application that doesn't support an
extension already rejects such templates at decode via
supported_extensions — no production caller passes a mismatched
context.

With mismatch impossible, every evaluation error at job creation is a
real defect, so the checks now report them all, and the skip machinery
is deleted. That strictness immediately surfaced two latent bugs it
had been masking, both fixed here:

• Budgets bypassed inside conditionals. For x if test else y
  with a test only a worker can resolve (Session.*), the evaluator
  runs both branches and absorbs a single failing branch (run time may
  never take it). It also absorbed memory/operation budget errors —
  but those are spent in this evaluation no matter which branch run
  time takes, so a caller's lowered budget silently stopped applying.
  Budget errors now propagate; value errors are still absorbed.
• Path-format mismatch on Windows. create_job resolves
  everything (including let bindings) with POSIX-format paths, but
  the re-checks evaluated under the host format — so a path value
  flowing from a let binding into an arg drew a "Path format
  mismatch" error on Windows. The checks now evaluate under POSIX to
  match the values they read.

Also, the symbol-table seeding for these checks no longer discards
set failures (let _ =) — they propagate as ModelError, never a
panic, so language bindings surface them as exceptions.

What is the impact of this change?

Callers passing a context derived from the template (the norm,
via default_validation_context() or equivalent) see no change.
Evaluation errors that depend on parameter values now fail
create_job instead of every session that runs the job. Lowered
evaluation budgets are enforced inside unresolved conditionals, the
idiomatic construction.

How was this change tested?

• cargo clippy --all-features --all-targets --workspace -- -D warnings clean.
• cargo test for expr/model/cli green, including new tests: contract
  rejection message, value-dependent evaluation errors reported at
  create_job, budget propagation out of unresolved conditionals
  (pinned at both the expr and model level), value-error absorption
  control, and path-format agreement.
• Conformance suite: 1139/1139.

Was this change documented?

Yes — create_job and FsEval docs, specs/model/job-creation.md
(error policy, ctx contract), specs/model/public-api.md, and
specs/expr/evaluator.md (IfExp absorption and its budget exemption).

Is this a breaking change?

Yes. create_job returns a Compatibility error when the context's
revision differs from the template's or its extensions don't cover the
template's declared ones. Callers deliberately stripping extensions at
job creation must instead reject the template at decode via
supported_extensions.

Does this change impact security?

No new files or permissions. Enforcement-wise it strengthens the
caller-limits story: evaluation budgets can no longer be bypassed via
unresolved-test conditionals.

---

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

[wyongzhi]

This PR makes create_job stricter: if you hand it a context that enables fewer extensions than the template itself declares, it now refuses with a Compatibility error instead of quietly running. That matters because #404 taught create_job to re-validate commands, env vars and embedded files after the real parameter values are plugged in, and that re-validation only makes sense if the context is at least as wide as what the template asked for. Every caller we could find already builds its context from the template (CLI, JS bindings, the Python bindings' default, and Deadline Cloud's DataPlane which passes none), so nothing on our side breaks.

[leongdl]

Regression: strict eval errors at create_job reject a template that openjd check passes and that runs

The contract change and the two bug fixes look right to me, and the POSIX switch matches what
openjd-model-for-python's _let_bindings.py does for the same stated reason. One problem with
making the re-checks strict: Unresolved propagation is not complete, so a valid template is now
refused at submission.

Repro

specificationVersion: jobtemplate-2023-09
extensions: [EXPR]
name: LcFilter
parameterDefinitions:
  - name: Files
    type: STRING
steps:
  - name: Render
    parameterSpace:
      taskParameterDefinitions:
        - name: Skip
          type: STRING
          range: ["b"]
    script:
      actions:
        onRun:
          command: echo
          args: ["{{ [f for f in Param.Files.split(',') if f != Task.Param.Skip] }}"]

Built openjd-cli at 70cd40b and at f0c5601, same template, same inputs:

	base 70cd40b	this PR f0c5601
openjd check	passes	passes
openjd summary -p Files=a,b,c (runs create_job)	succeeds	fails
openjd run -p Files=a,b,c --step Render	succeeds, prints a c	blocked by create_job

ERROR: Model validation error: 1 validation error for JobTemplate
steps[0] -> script -> actions -> onRun -> args[0]:
	Failed to parse interpolation expression at [0, 65]. List comprehension filter must be a boolean, got unresolved[bool]
  [f for f in Param.Files.split(',') if f != Task.Param.Skip]
                                        ^~~~~~~~~~~~~~~~~~~~

Mechanism

eval_listcomp has two paths and they disagree about Unresolved filters.

The unresolved-iterable path accepts one explicitly — is_bool_compatible tests
cond_inner.code() == TypeCode::Unresolved alongside BOOL, Any and a BOOL-containing
union. The concrete-iterable path does not: it requires ExprValue::Bool and errors otherwise.

Which path runs depends on the iterable, and the iterable's concreteness changes per stage:

• pass 8: Param.Files is Unresolved, so the iterable is unresolved, tolerant path, Ok.
• create_job: Param.Files is bound and Task.Param.Skip is not, so the iterable is concrete
  and the filter is unresolved[bool]. Strict path, Err.
• run time: everything is bound, filter is a concrete bool, Ok.

So the failure is specific to a symbol-table state that exists at no other stage — Param.*
concrete, Task.*/Session.* unresolved. The error kind is Other(..), which is why the
report_eval_errors early-return this PR deletes was swallowing it. The defect predates the PR;
this PR makes it reachable.

eval_boolop already takes the position I think eval_listcomp should take here, and
specs/expr/evaluator.md states it: "Errors in operands past the unresolved one are suppressed,
since a runtime short-circuit could make them unreachable." eval_ifexp says the same thing one
section down. eval_listcomp's concrete-iterable filter is the one place an unresolved value
produces a hard error instead of an Unresolved result.

This falsifies one of the new spec sentences

specs/model/job-creation.md, under Error policy:

so an evaluation error at this stage cannot be a context artifact: it is either a template
defect pass 8 missed or a deterministic value-dependent failure that every session resolving
the field would hit.

The repro above is a third thing. Not a template defect — pass 8 accepts it, correctly, because at
run time the filter is a concrete bool. Not a failure every session would hit — every session
resolves it fine. It is an artifact of partial resolution, an axis the context contract does not
address.

I would not fix this by rewording the sentence alone. That leaves a template that decodes, would
run, and is rejected at submission. The narrow code fix: on the concrete-iterable path, when the
filter evaluates to Unresolved, abandon the accumulated result and return
unresolved(list[body_type]) — per-element inclusion is undecidable, so the whole comprehension is
unknown, which is what the unresolved-iterable path already concludes via
unresolved_list_from_elements. Around ten lines, plus keeping absorb_counters and the
regex_cache restore on the new exit path. Then the sentence holds, with the caveat that it is
asserting an exhaustive disjunction and a future partial-resolution asymmetry would falsify it
again.

Scope, honestly

I looked for how often this triggers and found nothing. Across the repo's fixtures, tests and spec
examples, deadline-cloud-samples, and openjd-specifications, there are nine distinct
comprehension-with-filter forms and all nine filter on the loop variable or on Param.*, both
concrete at job creation. None references Task.* or Session.*. So this is a verified regression
with no template on hand that trips it.

What makes me raise it anyway is the spec sentence rather than the reachability. A documented
invariant that is false is what stops the next reader checking.

The other finding is separate

eval_boolop did not get the budget exemption eval_ifexp got, so the bypass survives behind an or. Split out into its own comment: #407 (comment)

Verified and not verified

Verified at f0c5601: cargo fmt --check clean, cargo clippy --all-features --all-targets --workspace -- -D warnings clean, workspace suite green. Both items above reproduced by running
code, base against tip.

Not verified: anything on Windows or macOS, so I could not exercise the path-format fix — note its
test is a no-op on Linux and macOS, since PathFormat::host() is Posix there. Reverting
path_format to host() leaves that test green on two of the three CI lanes. It does fail on
windows-latest, which the matrix runs, so the fix is pinned in CI but not on any Linux dev
machine. I also did not re-run the conformance suite or the mutation checks.

[leongdl]

eval_boolop did not get the budget exemption that eval_ifexp did

The budget fix landed in eval_ifexp only. eval_boolop suppresses errors on the identical
rationale and still absorbs a budget exceedance, so the bypass this PR closes is reachable by
moving the expensive subexpression behind an or, and wrapping the newly-fixed eval_ifexp in
one or re-absorbs the error it just propagated.

Example

Probed against this branch, Session.Flag seeded as Unresolved(BOOL), memory budget 1 MiB,
'A' * 10000000 costing ~10 MB:

expression	result
'A' * 10000000 if Session.Flag else 'B'	propagates — the arm this PR tests
'B' if Session.Flag else 'A' * 10000000	propagates — mirror arm, no test
Session.Flag or ('A' * 10000000 == 'x')	absorbed, peak_memory 264
Session.Flag and ('A' * 10000000 == 'x')	absorbed
Session.Flag or (('A' * 10000000 if Session.Flag else 'B') == 'x')	absorbed
int('nope') if Session.Flag else 7	absorbed — correct, the control

Why

eval_boolop's suppression arm is

Err(_) => { /* suppressed — unresolved might short-circuit */ }

and specs/expr/evaluator.md gives the reason: "Errors in operands past the unresolved one are
suppressed, since a runtime short-circuit could make them unreachable." That holds for a value
error and not for a budget, for exactly the reason contains_budget_error's new doc comment gives
for IfExp — the memory and operations were spent in this evaluation no matter which operand run
time would reach. peak_memory reporting 264 bytes after a 10 MB allocation is the same accounting
gap seen from the other side.

Three lines: the same contains_budget_error check in that arm. Worth doing here because the PR
description states budgets can no longer be bypassed via unresolved-test conditionals, and a test
for it would also close the (Ok(b), Err(oe)) gap above — both existing budget tests put the
failure in the if-branch, so deleting that arm's early return leaves the suite green.

Separately in the same area, eval_listcomp returns child.eval_node(..)? before
self.absorb_counters(&child), so a failing comprehension's child-evaluator spend is discarded —
the same "cost already spent" leak, for the case eval_ifexp deliberately absorbs. Not part of
this PR's scope; noting it so it is written down somewhere.

[leongdl]

Nit, not blocking — ship it.

The sub_errors() recursion here is load-bearing but has no test. I found it by
mutation: deleting the || err.sub_errors().iter().any(contains_budget_error) clause
leaves the entire workspace suite green, 7785 tests, including the five budget
tests added in f0152a5.

It is not dead code, and I want to be precise about that. The one construct that
attaches sub-errors is eval_ifexp's (Err, Err) arm, and a compound from there does
flow through a boolop. Measured, 1 MiB budget, Session.Flag unresolved:

Session.Flag or ('A' * 10000000 if Session.Flag else int('nope')) == 'x'

	result
as shipped	Err — "Both branches fail in the if/else: …" propagates
recursion clause deleted	Ok(unresolved) — absorbed, budget silently bypassed

So the clause is exactly the fix for a real bypass, it just has no falsifying test.
The new boolop_does_not_reabsorb_budget_error_from_nested_conditional does not reach
it: its inner ifexp takes the (Err, Ok) arm, which returns a bare
MemoryLimitExceeded with no sub-errors, so the matches! arm answers first.

Suggestion, whenever convenient: the expression above as a test next to that one. The
risk otherwise is a future refactor deleting the clause with a green suite, which
reopens the bypass for exactly the compound case the new doc comment above describes.

One related gap for the backlog rather than this PR. specs/model/job-creation.md now
says budget errors "propagate out of every construct that absorbs errors under an
unresolved operand". eval_attribute can still defeat that: its dotted-path arm
rewrites a failed base evaluation as UndefinedVariable, and its property arm
discards the original into a fresh error, neither attaching sub-errors — so a budget
error raised inside either is invisible to contains_budget_error and gets absorbed
by an enclosing or. I have not constructed a reaching expression, so treat it as
plausible rather than confirmed. Worth either narrowing the spec sentence or attaching
sub-errors at those two sites.

For the record on the rest of the revision: both of my earlier findings are fixed and
I mutation-checked both. Reverting else if cond.is_unresolved() in eval_listcomp
fails five expr tests plus listcomp_with_task_param_filter_over_bound_param_passes_create_job;
reverting the contains_budget_error early return in eval_boolop fails three
test_memory tests. cargo fmt, clippy -D warnings and cargo test --workspace
(7785 passed, 0 failed) all clean at f39387d2.

The listcomp fix is also better-shaped than what I proposed. Re-deriving the body type
under an unresolved loop variable, rather than mirroring is_bool_compatible in place,
is what keeps [10 // x for x in [0, 2] if x > N] from raising at job creation — my
version would have got that wrong.