fix(model): Resume deferred validation after format-string resolution

[leongdl]

What

Three constraints were correctly deferred past decode because their value was a format string, and then never resumed at job creation. Two commits, one defect shape.

A field annotated @fmtstring can hold a value that is unknown at decode, so a constraint on that value cannot be applied there. Decode does the right thing and skips the check. Job creation resolves the value, so that is where the check belongs. It was missing.

Commit 1: attribute capability values

hostRequirements.attributes[].anyOf and .allOf are @fmtstring in base 2023-09 with no extension gate, and their element type <AttributeCapabilityValue> (§3.3.2.2) constrains the value to an identifier-like pattern with a 100-character limit. validate_v2023_09::structure gates its check on FormatString::is_literal, correctly. Nothing re-checked after resolution, so this ran to completion:

parameterDefinitions:
- name: Software
  type: STRING
  default: "not valid!"
steps:
- name: Step1
  hostRequirements:
    attributes:
    - name: attr.custom.software
      anyOf: ['{{Param.Software}}']

resolve_host_requirements now re-checks each resolved element through a new
capabilities::validate_attribute_capability_value. The error carries the same path and
wording as the decode-time check, so the violation reads identically whether the value was
written literally or arrived through a parameter:

steps[0] -> hostRequirements -> attributes[0] -> anyOf[0]:
	value 'not valid!' contains invalid characters.

The standard-capability branch is exclusive, matching the reference implementation: a standard capability is checked against its value set only, not against the identifier pattern or the length limit.

instantiate_step gained a step index so the path can name the step. That takes it to six parameters, which is over this repo's comfortable limit, and it is there to make the error path identical to decode's.

Commit 2: amount bounds, and chunk counts

hostRequirements.amounts[].min and .max may be format strings under FEATURE_BUNDLE_1. The decode checks read parse_literal_amount, which returns None for a non-literal, so min non-negative, max positive and min <= max were skipped together. Job creation checked only that the resolved text parsed as a finite number. A max resolving to 0 was accepted even though max is <positivefloat> while min is <nonnegativefloat>. check_resolved_amount_bounds re-applies all three.

chunks.defaultTaskCount and .targetRuntimeSeconds were worse than unchecked. Job creation resolved them and then clamped, with .max(1) and .max(0). A defaultTaskCount resolving to 0 silently became 1, and the job ran with a chunk shape its author never asked for — the observed log was five one-task chunks. Both now reject the out-of-range value. The literal arms clamped too, but decode rejects an out-of-range literal, so those clamps were unreachable.

Why it matters

These are the four proposed/ fixtures in openjd-specifications#179, which exist because the Python reference implementation rejects all four and this one accepted all four. With this PR all four pass here as well, so they can be promoted into the live suite once openjd-cli ships from crates.io. The spec repo's Rust conformance job installs the published release, so promoting before then would turn that leg red.

Verification

cargo test --workspace 7338 passed, 0 failed, up 24 from 7314. Full OpenJD conformance suite 1174 passed, 0 failed, unchanged from before either commit. cargo clippy --all-features --all-targets --workspace -- -D warnings clean. cargo fmt --all -- --check clean.

24 tests added. Every one was mutation-checked, which means the fix was reverted one behaviour at a time and the matching test confirmed to fail: 8 mutants on commit 1 and 8 on commit 2, 16 of 16 caught, verified independently by a second auditor that ran its own 14 mutants against commit 1. Two are worth naming. One pins min of 0 as accepted where max of 0 is rejected, so a check written as min <= 0.0 fails it. Another pins the boundary defaultTaskCount of 1 as carried through as 1, so restoring the clamp fails it rather than passing by coincidence.

specs/model/capabilities.md, public-api.md, job-creation.md and validation.md are updated in the same commits, per the repo's spec-and-code rule. validate_attribute_capability_value is new public API and is in public-api.md.

Known remaining gaps, documented not fixed

specs/model/validation.md now states these rather than leaving them implied.

Only the first failing anyOf/allOf group on the first failing attribute is reported, because the caller collects through ?. Decode accumulates every violation. Closing that means threading one ValidationErrors through the whole of resolve_host_requirements.

Decode applies the element length and emptiness checks to the raw text of a format string, not only to literals, so a format string longer than 100 characters is rejected at decode even when it resolves to a short value. Verified: a 130-character element built from two 55-character parameter names resolving to shortshort is rejected with exceeds 100 characters. That is arguably its own defect and is out of scope here.

[seant-aws]

NIT (ranges.rs): The two new chunk-bound errors (defaultTaskCount resolved to < 1, targetRuntimeSeconds resolved to < 0) use bare ModelError::Expression with no field path, while:

• Decode-time equivalents in validate_v2023_09/task_chunking.rs report full paths like steps[0] -> parameterSpace -> taskParameterDefinitions[0] -> chunks: defaultTaskCount must be >= 1.
• The other two fixes in this same PR (check_resolved_amount_bounds, check_resolved_attribute_values) both thread step_index and build proper ValidationErrors paths.

Since step_index is already plumbed through instantiate_step → resolve_host_requirements, it would be consistent to thread it into resolve_task_parameter as well and emit path-prefixed errors here too — matching both decode and the rest of this PR.

Not a blocker — the error messages themselves are clear and tested — but it's the one place the diagnostics format diverges from the repo's "assert path + message" standard (AGENTS.md).

[leongdl]

NIT (ranges.rs): The two new chunk-bound errors (defaultTaskCount resolved to < 1, targetRuntimeSeconds resolved to < 0) use bare ModelError::Expression with no field path, while:

• Decode-time equivalents in validate_v2023_09/task_chunking.rs report full paths like steps[0] -> parameterSpace -> taskParameterDefinitions[0] -> chunks: defaultTaskCount must be >= 1.
• The other two fixes in this same PR (check_resolved_amount_bounds, check_resolved_attribute_values) both thread step_index and build proper ValidationErrors paths.

Since step_index is already plumbed through instantiate_step → resolve_host_requirements, it would be consistent to thread it into resolve_task_parameter as well and emit path-prefixed errors here too — matching both decode and the rest of this PR.

Not a blocker — the error messages themselves are clear and tested — but it's the one place the diagnostics format diverges from the repo's "assert path + message" standard (AGENTS.md).

I will make a follow up PR to upgrade the error messages. This one can unlock conformance testing.