fix: bump openjd-rs crate deps to 0.4.0/0.5.2/0.5.2

[leongdl]

Picks up the crates published by openjd-rs#332.

crate	before	after
openjd-expr	0.3.0	0.4.0
openjd-model	0.5.0 (resolved 0.5.1)	0.5.2
openjd-sessions	0.5.0 (resolved 0.5.1)	0.5.2

No binding source changes were needed — openjd-expr 0.4.0's coercion split
(openjd-rs#329) does not touch any
API rust-bindings/ calls, so this is a pin bump, Cargo.lock, and the regenerated
THIRD-PARTY-LICENSES.txt.

Behaviour change worth a reviewer's attention

openjd-model #334 reaches Python
through deserialize_step, which the worker uses to rebuild a step:

• "let" is now accepted as the wire key (previously only "letBindings" was, so "let" was
  silently dropped and expressions referencing those bindings failed with "Undefined variable").
• StepScript/EnvironmentScript gained deny_unknown_fields, so an unrecognised script key
  now raises instead of being ignored:
  ValueError: failed to deserialize Step: unknown field 'bogus', expected one of 'let', 'letBindings', 'actions', 'embeddedFiles'

Both verified against the rebuilt extension. The tightening is the only outward-facing
regression risk here; upstream shipped it as a patch release, hence fix: rather than feat!:.

Also in the pickup: list-parameter element coercion
(#335), symbol-table parameter
coercion (#330), list-to-string
element escaping (#336), and seven
overflow/panic/silent-wrong-value fixes (#321).

Testing

check	result
cargo build --manifest-path rust-bindings/Cargo.toml --all-targets	pass
cargo clippy --manifest-path rust-bindings/Cargo.toml --all-targets -- -D warnings	pass
cargo test --manifest-path rust-bindings/Cargo.toml (+ --doc)	pass (no tests in crate)
hatch run test against a rebuilt extension	5479 passed, 24 skipped, 3 xfailed
scripts/check_third_party_licenses.sh	up to date

No xfail in test_known_gaps.py xpassed, so nothing needed re-homing.

Local hatch run test reports 93.98% against the 94% gate. That number is identical before and
after the bump (same missed lines with the 0.5.1 and 0.5.2 extensions) and comes from 24 tests
skipped in my environment, not from this change.

[github-actions]

openjd-expr 0.3.0 -> 0.4.0 is a SemVer-breaking bump for a 0.x crate, and this PR changes no binding source. Two of the mirrored enums in rust-bindings/src/expr/profile.rs fail silently rather than at compile time, so neither cargo build nor the existing test suite would catch drift here.

1. ExprRevision — silent mislabeling. From<ExprRevision> for PyExprRevision (profile.rs:105-115) has a wildcard arm mapping any unknown upstream variant back to V2026_02, guarded by allow(unreachable_patterns). If 0.4.0 added a revision and moved ExprRevision::CURRENT to it, then ExprProfile() — which resolves to ExprRevision::CURRENT at profile.rs:395 — would build a profile on the new revision while the revision getter reports ExprRevision.V2026_02, and the Python ExprRevision.CURRENT classattr (profile.rs:61) would still be pinned to the old variant. The wildcard suppresses the non-exhaustive-match warning, so the build stays green. No test asserts the mapping either: test_equality.py:190 only compares CURRENT == CURRENT, and test_pickle.py:80 only round-trips the literal V2026_02 — both pass regardless. __repr__ at profile.rs:487-491 has the same wildcard.

2. ExprExtension — import-time panic. PyExprExtension::ALL (profile.rs:152-160) maps over ExprExtension::ALL through From<ExprExtension>, whose body is unreachable!("ExprExtension has no variants in this crate version") (profile.rs:178-183). If 0.4.0 shipped the first ExprExtension variant, this panics — and because ALL is a classattr, it fires during module import, not on first use.

Worth confirming against the 0.4.0 release notes that neither enum gained a variant. If they did not, consider replacing the ExprRevision wildcard with a loud failure — matching how ExprValue and TypeCode already handle this at expr_value.rs:179 and expr_type.rs:76 — so the next bump breaks the build instead of quietly reporting the wrong revision.