Make verifier challenge cases language-neutral data

[aruintelligence]

Clean-room interoperability hardening

The External Verifier Challenge previously described its cases in JSON, but the exact tampered inputs were still constructed inside scripts/run-verifier-conformance.mjs. An outside implementer therefore had to inspect or execute reference harness code to know the precise mutation bytes.

Fix

• add conformance/verifier-challenge-cases.json (aml-verifier-challenge-cases/1);
• define exact evaluation time, expected validity and mutations as data;
• mutations use the narrow aml-json-pointer-replace/1 profile with RFC 6901 JSON Pointer paths;
• make conformance/verifier-challenge.json point at the case corpus instead of duplicating prose mutations;
• make the black-box harness load and execute the case corpus rather than hard-code purposeTamper / challengeTamper objects;
• include the case corpus in the reference-code-free External Verifier Kit;
• regression-test the exact historical cases and prove the harness consumes the corpus.

Compatibility

The four externally visible cases and their expected results are unchanged:

• golden-valid → true;
• tampered-purpose → false;
• tampered-challenge → false;
• expired-challenge → false.

The exact historical tamper values are preserved.

Evidence boundary

This makes the challenge inputs independently readable and reproducible without reading reference harness source. Matching the corpus is still project-defined black-box interoperability evidence, not certification or proof of implementation independence.

Author: Daniel Jacob Read IV
Steward: ĀRU Intelligence Inc.™