A step-level EXPR `let` binding was evaluated with the host's path format.
openjd-rs evaluates template-scope expressions with `PathFormat::Posix`
(create_job/instantiate.rs, create_job/mod.rs) so that a create-time result
cannot depend on the host that created the job. This implementation used the
engine default, which is the host's format, so on Windows
`startswith(path("/foo/bar"), "/foo")` evaluated to false where the Rust
implementation gives true, and `string(path("/mnt/out"))` rendered
`\mnt\out` rather than `/mnt/out`.

`evaluate_let_bindings` now takes a `path_format`, and
`StepTemplate._extend_step_symtab` passes `PathFormat.POSIX`. The default
stays `None` (the engine default) so every session-scope caller is unchanged.

The instantiated `StepScript` also records `_template_scope_let_count`, the
number of leading entries in its merged `let` list that came from the step.
The merge itself is unchanged, because consumers that do not pass a resolved
symbol table to `Session.run_task` rely on it. openjd-sessions reads the count
to re-evaluate that prefix in template scope rather than in the host's, and
reads it through `getattr` with a default of 0, so an older openjd-model
degrades to the previous behaviour. It is a `PrivateAttr`, so the serialized
form of the model does not change.

This is the openjd-model half of a two-repo fix. Without the openjd-sessions
half, a step-level binding is still re-evaluated in host scope at session
time, so the 11 Python-on-Windows conformance failures this addresses need
both halves.

Signed-off-by: David Leong <116610336+leongdl@users.noreply.github.com>

Two defects in the previous commit, both found by local review.

The boundary was recorded only by `Step._record_template_scope_let_count`, an
after-validator on `Step`. A consumer that parses a `StepTemplate` and runs
`resolve_syntax_sugar()` on it never constructs a `Step`, so the validator
never ran and the boundary was lost. The Deadline worker agent does exactly
that, via BatchGetJobEntity, so the fix reached `openjd-cli` and not the
worker. Measured before: `create_job` gave a count of 2 and the
resolve_syntax_sugar path gave nothing. The count is now set at the merge site
as well, and both paths give 2.

The validator also set the count to `len(self.let)` without checking that
`script.let` actually starts with `self.let`. It runs for a `Step` built
directly, where nothing guarantees that. A mismatch recorded a count that would
make a session evaluate a genuinely session-scope binding in template scope. It
now verifies the prefix and records 0 when it does not match, which is the
previous behaviour.

The attribute's comment claimed a session "must skip" the prefix. It
reproduces it in template scope and re-tags the result to host format instead,
so the comment is corrected to say that.

Signed-off-by: David Leong <116610336+leongdl@users.noreply.github.com>

The generator script fails on BSD sed, so the two version lines CI reported are
bumped by hand: pydantic 2.13.4 to 2.13.5 and pydantic_core 2.46.4 to 2.46.5.

Signed-off-by: David Leong <116610336+leongdl@users.noreply.github.com>

A step's template-scope `let` is already resolved at job creation and
travels in the step symbol table returned by
create_job_with_symbol_tables(...).step_symbol_tables[step_name]. For a
step-level let of ["a = 1", "root = path('/foo/bar')",
"txt = string(path('/mnt/out'))"] that table holds `a` int 1, `root` path
'/foo/bar' stored POSIX, and `txt` string '/mnt/out', with the
script-level let correctly absent. The worker agent forwards that table to
openjd-sessions as of 08a5878b and deleted its extra_let_bindings channel
outright.

Merging the step-level let into script.let for the runtime to re-evaluate
is therefore redundant, and harmful: when both run, the session-side
re-evaluation writes last and clobbers the correctly formatted seeded
value.

Removed:
- the merge in the `script:` branch of StepTemplate.resolve_syntax_sugar
- the merge in the SimpleAction sugar branch
- the Step after-validator _record_template_scope_let_count
- the _template_scope_let_count PrivateAttr on StepScript

The create-time step-scope evaluation that populates the step symbol
table is unchanged, and Step.let remains a model field -- it just stops
being merged into the script.

Deleted TestTemplateScopeLetCount, which tested the removed machinery,
and added tests pinning the new contract: resolve_syntax_sugar leaves
script.let holding only the script's own bindings (both the `script:`
branch and all five SimpleAction interpreters), the step-level bindings
arrive in the step symbol table with a PATH value rendering /foo/bar
under POSIX and \foo\bar under WINDOWS, and the script-level let is
absent from that table.

Signed-off-by: David Leong <116610336+leongdl@users.noreply.github.com>

The comment justified running the symbol-table hook before the transform
by saying StepTemplate's syntax-sugar transform folds step-level `let`
bindings into the script. That fold was deleted in the previous commit,
so the stated reason no longer exists -- but the ordering is still
load-bearing, and this comment was its only record.

Restate the two reasons that survive:

* A transform may rebuild the model rather than adjust it --
  `resolve_syntax_sugar` returns a `model_construct`ed StepTemplate -- so
  the fields the hook reads (`name`, `let`) are only guaranteed to be the
  authored ones on this side of it. The transform carries `let` through
  deliberately; running the hook first keeps that the transform's choice
  rather than a requirement on every future one.
* `create_job_with_symbol_tables` invokes the same hook on the same
  untransformed StepTemplate to build the step symbol table it publishes
  for the runtime. That table is only the scope the step's own fields
  were instantiated against if both callers hand the hook the same model.

Comment only; no behaviour change.

Signed-off-by: David Leong <116610336+leongdl@users.noreply.github.com>