feat(measure): vendor dqm-content-cms-2025 (US Quality Core refactored measures) and re-point the MADiE harness

[Taleef7]

The track's USQC Refactored Measure Parity/Discrepancy Testing scenario: evaluate the cqframework/dqm-content-cms-2025 test cases — the same 2025AU measures refactored QI-Core → US Quality Core (0.1.0-cibuild, moving to published 0.5.0), same per-patient input/tests/measure/<Name>/<patient>/ format the existing MADiE gate already consumes. All 8 gated measures (CMS2/68/122/125/130/138/165/951) are in the repo (~74 measures incl. CMS816/NHSN).

• Vendor the 8 measures' USQC bundles + terminology (same pinning discipline as ADR-036/041; terminology release ecqm-fhir-update-2025, same 1000-code cap handling)
• Re-point/duplicate the MADiE harness at the USQC content; produce a per-measure QI-Core-vs-USQC comparison (the existing 410/410 is the before; the USQC run is the after)
• Record discrepancies in the track's classification shape (the repo's own scripts/comparison/discrepancy_report.md pattern)
• Known unknown to resolve early: whether the USQC content's retrieves behave under our meta.profile-sensitive preparation (we execute pre-compiled ELM, so translator differences should not bite — verify)

Success per the track page: all test cases pass; bonus tier is the NHSN measures. Context: docs/JOURNAL.md 2026-08-24; ROADMAP M-D0 (re-aim at US Quality Core) — this is that milestone's concrete first step.

[Taleef7]

Bounded translation spike (2026-08-25): the named unknown is answered — USQC content compiles under the JS translator, 6/8 clean, and the 2 failures are ONE upstream translator gap.

Setup. All spike inputs fetched pinned: cqframework/dqm-content-cms-2025 @ 9f5f2298 (measure CQL + usqualitycore-modelinfo-0.1.0-cibuild.xml + shared libs), HL7/us-cql-ig @ tag 2.0.0-ballot (USCoreCommon, USCoreElements, CumulativeMedicationDuration, uscore-modelinfo-6.1.0-derived.xml), HL7/cql-ig published STU2 (FHIRCommon 2.0.0). Translator: our runtime @cqframework/cql 4.0.0-beta.1 wiring (same ModelManager/LibraryManager pattern as compile-measures.mjs), with the USQualityCore + USCore modelinfos registered as additional model providers.

Results (all 8 target measures):

measure	result
CMS122, CMS125, CMS130, CMS165, CMS2, CMS68	0 errors (10–26 statements each)
CMS138, CMS951	fail on exactly one operator: Could not resolve call to operator prevalenceInterval with signature (choice<USQualityCore.ConditionProblemsHealthConcerns,USQualityCore.ConditionEncounterDiagnosis>)

The shared failure is a JS-translator gap, minimally reproduced (8 lines): prevalenceInterval is declared in FHIRCommon on FHIR.Condition. A retrieve of a single USQC Condition profile converts profile→base and resolves; a union of two Condition profiles produces a choice type, and the JS translator does not resolve choice<A,B> against a signature both alternatives convert to. [ConditionEncounterDiagnosis] C return C.prevalenceInterval() compiles; ([ConditionProblemsHealthConcerns] union [ConditionEncounterDiagnosis]) C return C.prevalenceInterval() does not. The Java toolchain accepts these measures (the repo commits Java-built ELM XML for CMS125/CMS2). Candidate upstream issue against cqframework/clinical_quality_language KMP JS.

Two API findings for our own wiring:

• Namespaced includes (include hl7.fhir.uv.cql.FHIRHelpers …) require namespace registration; the curated cql-to-elm JS surface exposes no NamespaceInfo — the spike reached the Kotlin-mangled export (NamespaceInfo39vawc1900m2u from the cql subpath) and then modelManager.namespaceManager.ensureNamespaceRegistered(...) works. Worth an upstream API request alongside the choice-type issue.
• Include-version matching is enforced (2.0.0 vs 2.0.0-ballot refuses), so vendoring must carry exact-version sources.

Also relevant to vendoring: the measure CQL headers carry "For use by March 2026 US Realm Connectathon participants for internal use only. Not for use or distribution in commercial products." — distribution posture needs the community question answered before this content lands in the public repo.

Spike artifacts (script + fetched closure) are local-only scratch; nothing committed.

[Taleef7]

The spike's translator gap is now filed upstream: cqframework/clinical_quality_language#1831 — tightened to a 7-line repro before filing: not fluent-specific (plain function calls fail identically), the explicit cast workaround is also refused, and confirmed on 5.2.0 (latest), so the #479 upgrade will not fix CMS138/CMS951. Java-3.27.0-accepts evidence taken from the committed CMS951 ELM in dqm-content-qicore-2025. Offered to test candidate fixes against the eight-measure set.