test: Add §3.4 range-cap and §7.3.1 Step.Name job conformance fixtures

[leongdl]

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

Review of the RFC 0007/0008 implementation stack (openjd-model-for-python #318/#313, openjd-sessions-for-python #333, openjd-cli #230) found two spec-observable behaviors that no conformance fixture pinned — both had silently diverged between the Python and Rust implementations:

1. Template Schemas §3.4 range cap at job creation: the 1024-value task-parameter range cap was only exercised for literal template ranges (parse time). Expression-driven ranges — a typed whole-field "{{Param.Values}}" over a LIST[*] parameter, or a supplied RANGE_EXPR — are only expanded at job creation, where openjd-rs enforced the cap but the Python model did not.
2. RFC 0007 §7.3.1 Step.Name in step environments at run time: static acceptance was pinned, but no runtime fixture verified Step.Name resolves inside a step environment's actions — the Rust CLI passed this while the Python CLI failed it.

What was the solution? (How)

Four fixtures in conformance-tests/2023-09/EXPR/jobs/:

• 3.4--range-from-list-param-too-long.invalid.test.yaml — supplied LIST[INT] of 1025 items via a typed whole-field range; decode-clean, must fail at job creation.
• 3.4--range-expr-supplied-value-too-long.invalid.test.yaml — supplied RANGE_EXPR "1-1025"; decode-clean, must fail at job creation.
• 3.4--range-from-list-param-at-limit.test.yaml — exactly 1024 values accepted (guards the off-by-one an at-the-cap rejection bug would introduce). Note: runs 1024 trivial tasks — seconds on the Rust CLI, ~3 minutes on the Python CLI; the fixture header documents this.
• 7.3.1--step-name-in-step-environment.test.yaml — Step.Name resolves in a step environment's onEnter/onExit at run time, directly and through a step-level let binding. (Negative polarity — Step.Name rejected in job environments — already exists as decode-time .invalid fixtures.)

How was this change tested?

All four fixtures validated against both implementations via run_openjd_cli_tests.py: the openjd-rs release CLI, and the Python CLI running the fixed RFC 0007/0008 branches. Both .invalid templates confirmed decode-clean (openjd check passes on both CLIs), failing only at job creation.