test: Add a §2 task parameter type case-insensitivity fixture

[leongdl]

Adds one conformance fixture: 2023-09/EXPR/job_templates/3.4.1--task-param-type-case-insensitive.yaml.

What it pins

Template Schemas §2 makes job and task parameter type names case-insensitive when the EXPR extension is enabled. The case was implemented for job parameter types only, so a task parameter spelled type: int was rejected with EXPR declared:

steps[0] -> parameterSpace -> taskParameterDefinitions[0]:
	Input tag 'int' found using 'type' does not match any of the expected tags: INT, FLOAT, STRING, PATH, CHUNK[INT]

The fixture covers the four task parameter types of §3.4.1 — int, Float, sTrInG, pAtH — and must validate.

Status: red until two releases ship

Both implementations have merged the fix, and neither has released it:

Lane	Installs	Contains the fix?
Python	pip install openjd-cli → openjd-model 0.11.9	No. openjd-model-for-python#350 merged 2026-09-09, after the 0.11.9 tag
Rust	cargo install openjd-cli → 0.1.14	No. openjd-rs#364 merged, and 0.1.14 predates it

Measured, not inferred: the released Python CLI rejects the fixture, and a build of openjd-rs main accepts it.

Neither release is queued, and each needs a deliberate act:

• openjd-model-for-python: dispatch release_bump.yml (manual workflow_dispatch), which lands a CHANGELOG bump on mainline and triggers publish.
• openjd-rs: merge the standing release PR #365, which does contain #364.

Once both are on PyPI and crates.io, this goes green with no further change here.

Changes from the previous revision

This branch previously parked four fixtures under job_templates/proposed/, which the runner does not scan — collection uses a non-recursive directory.glob("*.yaml") per kind directory, so nothing in proposed/ ever ran.

The case-insensitivity fixture is now an ordinary conformance test, and proposed/ plus its README are gone. The branch is also rebased onto mainline, which clears an unrelated failure: it carried the pre-rename 3.5--env-script-onexit-only.invalid.yaml, corrected upstream in 563c6ec.

The other three parked fixtures were dropped rather than promoted, because each still fails:

Fixture	Expected	openjd-rs main	openjd-model 0.11.9
2.10--range-expr-endpoint-int64-max	valid	rejects	accepts
2.13--list-int-item-int64-overflow.invalid	reject	accepts	accepts
2.16--list-list-int-inner-item-int64-overflow.invalid	reject	accepts	accepts

They pin genuine int64-bound defects — bounds are enforced for expression literals but not for values arriving as YAML data — and the two .invalid ones additionally depend on restoring the overflow-is-an-error text that was dropped from the published spec. Better raised on their own once those are addressed than carried in a PR that is otherwise ready.

Not covered, and worth adding

Nothing in the suite pins the other half of §2: that a lowercase task parameter type is still rejected without EXPR. Both implementations gate the fold on the extension, so a regression dropping that gate would pass the whole suite.

[leongdl]

Quorum verdict: GOOD-WITH-NITS — spec: §2.13 + EL §1.2.1 (LIST[INT] element bound). Matches sweep (fails BOTH — say so; README says 'the current openjd CLI' without attribution). Nits: only fixture family in the five PRs without in-file header comments — add one (the bound comes from the EL type table, not §2.13); carry the same 'pending restoration of the RFC 0005 overflow text' hedge the expr-lang README uses for the identical bound. Accept twin: PR #158's 2.13--list-int-item-int64-max.

[leongdl]

Quorum review (5 independent agents). 5 fixtures + 2 READMEs. Net: 3 GOOD, 2 GOOD-WITH-NITS. This branch's kind-level placement (EXPR/job_templates/proposed/, base/job_templates/proposed/) is the better convention of the two in use — promotion is 'move up one directory unchanged' — and the quorum recommends the other four expected-failures branches adopt it. Actions: dedupe 2--type-lowercase-string against PR #163's identical fixture; add per-implementation attribution to the README (sweep shows several entries fail BOTH or rs-only where the README is vague); add the missing header comments to the two list-overflow fixtures and carry the same spec-restoration hedge the expr-lang README uses for the identical int64 bound.

[leongdl]

Quorum-review fixes applied and pushed (rebased onto mainline 3069673):

• Dropped 2--type-lowercase-string.invalid.yaml and its README — it duplicated test: [expected failures] base fixtures needing implementation fixes #163's 2--type-lowercase.invalid.yaml (same construct, same rs-only defect); that branch's copy is the single source.
• README renamed to README-param-types.md (family-named, kind-level convention) so co-located expected-failures PRs can't add/add-conflict on a shared README path.
• Per-implementation attribution added: 2.13/2.16 list-overflow and 3.4.1 task-param case-insensitivity fail both implementations; 2.10--range-expr-endpoint-int64-max is rs-only (the quoted "Model validation error" format is genuinely openjd-rs output — same format as pydantic — re-verified against the current upstream/main build, where all four defects still reproduce).
• Added the dropped-RFC-0005-overflow-text hedge to the 2.13/2.16 entries (matching the expr-lang README) and header comments to both list-overflow fixtures.
• Noted the missing reject twin (task-param lowercase type WITHOUT EXPR) as a future addition.