test: Add conformance fixtures for two template-parsing divergences [DO NOT MERGE]

[leongdl]

Important

DO NOT MERGE YET. Opened as a draft on purpose. Each fixture here is
currently red on exactly one implementation, so merging before the two owning
bugs are fixed puts a permanent failure in both conformance suites. See
Merge sequencing below.

Adds two conformance fixtures for template-parsing (validation-time)
divergences found while reviewing RFC 0008 wrap-action support across the two
implementations. Neither was covered by the existing suite, which is why both
survived.

1. EXPR/jobs/7.3--task-file-direct-property-access.test.yaml

RFC 0005 declares Task.File.<name> and Env.File.<name> as path typed, and
shows property access on one directly inside a format string:

echo "Script: {{Task.File.Run.name}}"

An implementation whose template validator resolves a Task.File.* reference by
looking the whole dotted tail up as an embedded-file key rejects that form:

ERROR: Model validation error: references undefined embedded file 'Run.name'.

…even though its own runtime resolves the expression correctly, and its
environment-template validator accepts the equivalent Env.File.<name>.name.

Why it was uncovered. The existing 7.3--task-file-expr-properties fixture
reaches the property through a let binding (cfg = Task.File.config, then
cfg.parent), and a property reached inside a function call
(len(Task.File.Run.name)) parses differently again. I verified all three forms:
only the direct member-access form the RFC itself uses triggers the rejection,
and nothing exercised it.

filename is set in the fixture so the expected value of .name is
deterministic.

2. EXPR/job_templates/3--int-literal-above-int64-max.invalid.yaml

RFC 0005 §3 ("64-bit Signed Integer Type") bounds integers to −2⁶³ … 2⁶³−1 and
says any value outside that range is an error. This template's timeout is 2⁶³
(9223372036854775808), one past the maximum, so validation must reject it.

An implementation whose model has no upper bound accepts the template and only
discovers the problem at run time — or converts it into a native duration type
and overflows. Rejecting it at validation is what lets a submitter see the error
before the job is ever scheduled.

Verified against both reference CLIs

Fixture	openjd-rs	Python stack (openjd-cli / openjd-sessions / openjd-model)
1 — direct Task.File.* property access	fails at validation	passes
2 — integer literal above 2⁶³−1	passes (correctly rejects)	fails (accepts the template)

Each red is a tracked defect in a different implementation, and each fixture is
green on the other — which is the intended shape of a conformance test.

Merge sequencing

Merging this PR makes one suite red on each implementation until the owning bugs
land. Suggested order:

1. Fix the Task.File.<name> property-access validator in openjd-rs.
2. Add the integer upper bound to openjd-model-for-python.
3. Un-draft and merge this PR.

Alternatively merge it first, deliberately, as the failing test that drives both
fixes — happy either way, but it should be a conscious choice rather than a
surprise.

Related, not included

An INT parameter default above 2⁶³−1 (type: INT, default: 9223372036854775808)
is accepted by both implementations today, verified with openjd check on
both CLIs. RFC 0005 §3 says it should not be. I deliberately did not add a
fixture for it, because it would sit permanently red on both suites and needs a
decision first: either fix both models, or clarify that the integer domain
constrains expression evaluation rather than literal parameter defaults.

---

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