feat!: Bump openjd-* Rust crates to the openjd-model 0.13.0 release

[leongdl]

Fixes: n/a (dependency bump for OpenJobDescription/openjd-rs#425 and #438)

BREAKING CHANGE: create_job raises ModelValidationError at the binding's path instead of ExpressionError when a let binding fails. Some templates that decoded before are now rejected (see below). Building from source needs Rust 1.97.

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

openjd-rs released openjd-expr 0.11.0, openjd-model 0.12.0 and openjd-sessions 0.8.0 on 2026-10-07 (#425), then openjd-expr 0.12.0, openjd-model 0.13.0 and openjd-sessions 0.8.1 on 2026-10-15 (#438). This package pinned 0.10.1 / 0.11.0 / 0.7.3. openjd-sessions has no source change in either release.

What was the solution? (How)

Bump the three pins. The bindings compile unchanged, and cargo clippy --all-targets -- -D warnings is clean. Cargo.lock adds 20 transitive crates, mostly ICU crates pulled in by rustpython-ruff_* 0.16.10. THIRD-PARTY-LICENSES.txt was regenerated with scripts/check_third_party_licenses.sh --update. It adds Unicode-3.0, which deny.toml already allows, and also moves pydantic to 2.14.1 because the script resolves Python dependencies fresh.

What is the impact of this change?

Upstream	Python-visible effect	Measured
openjd-rs#428	A let failure in create_job is ModelValidationError at steps[0] -> script -> let[0] (or jobEnvironments[i] -> ...), with the caret under the full binding. All carried-forward check failures are reported together.	2/2
openjd-rs#429	Syntax errors use CPython's wording: '(' was never closed, unterminated string literal (detected at line 1). MSRV 1.97.	3/3
openjd-rs#434	Incompatible list types read int and string. Nested lists with mismatched element types are rejected.	1/1
openjd-rs#435	and/or after an unresolved operand is unresolved of the union of reachable operands. 10 // (X or Z) with Z = 0 no longer raises; (F and S).upper() now validates.	4/4, each different on 0.11.0
openjd-rs#424	C://scenes/a.ma is a path, not a URI with scheme c. s3:// is unchanged.	3/3, 2 different on 0.11.0, 1 control

How was this change tested?

• hatch run test: 6330 passed, 26 skipped, 5 xfailed, coverage 94.20%. No strict xfail flipped.
• hatch run lint clean (ruff, black, mypy). Regenerating the licences resolved pydantic 2.14.1, which types FieldInfo.annotation as TypeForm[Any]. mypy 2.3 then rejected passing it to two walkers in _internal/_variable_reference_validation.py declared model: Type. They already handle Unions and generic aliases, so the second commit types model as Any. No runtime change.
• cargo build --all-targets, cargo clippy --all-targets -- -D warnings and cargo test clean on Rust 1.99.0.

Tests updated (they pinned the old upstream behaviour): TestSyntaxErrorCarets (3), TestUnknownListLiterals::test_incompatible_types_error, TestCreateJobLetFailureMessages (2). New: TestBoolOpAfterAnUnresolvedOperand in test_unresolved_eval.py, TestSingleLetterSchemeIsAPath in test_uri_paths.py.

Mutation check: with the pins reverted and the extension rebuilt from source, all 6 updated tests and 6 of 7 new tests fail; the survivor is the s3:// control.

What could NOT be verified

• The v0 implementation was not compared against v1 for #435 and #424.
• The three-auditor review of the new tests was not run; the mutation results are the author's own.
• Windows and the Python 3.9 lane were not run locally.
• #428's re-check of parameter-dependent timeout / notifyPeriodInSeconds has no new Python test.

Was this change documented?

No spec text describes create_job's let-failure exception type. evaluate_let_bindings, which specs/python-model-interface.md documents, is unchanged upstream.

Is this a breaking change?

Yes. Callers catching ExpressionError from create_job for a let failure now get ModelValidationError. Templates may now be rejected that were accepted before: and/or expressions after an unresolved operand that fail for some member of the union (#435), list literals of lists with mismatched element types (#434), and parameter-dependent invalid timeouts, notify periods or cancelation modes (#428).

Does this change impact security?

No.

---

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

[github-actions]

Claude review · advisory

Reviewed e48f90f (changes since 2a56f57): 0 new, 0 resolved.

Open: 0 blocking · 0 should-fix · 0 nit. ✅ Nothing blocking.

_{Fix or reply to each thread; the next revision's review re-checks open threads and resolves those it agrees are handled. Resolving a thread yourself also closes it. Later revisions review only what changed.}