Fix IG/$data-requirements key ValueSet binding discovery

[c-schuler]

Summary

Make IG/$data-requirements emit the same key ValueSet bindings the IG-publisher shows in its "Key Elements Table". For abstract-framework IGs like hl7.fhir.uv.cql the operation previously surfaced zero ValueSets in relatedArtifact[] and zero entries with crmi-dependencyRole=key even though the IG-publisher's published key-elements analysis identifies several per profile. End-to-end verification against hl7.fhir.uv.cql 2.0.0: all 27 expected key ValueSets across 8 profiles (publication-status, library-type, mimetypes, structure-definition-kind, defined-types, related-artifact-type, etc.) now surface with crmi-dependencyRole=key.

Five independent gaps, each fixed independently:

1. Canonicals.getResourceType self-referential URL bug - used String.replace() (global) and mangled URLs like http://hl7.org/fhir/StructureDefinition/StructureDefinition to return "fhir". Switched to substring(0, lastIndexOf("/")). Without this, search-class lookup mis-routed FHIR meta-types to CodeSystem and the visitor never recursed into base FHIR profiles.

2. NpmRepository.search() lazy-load - only read() was wired to lazy-load NPM packages on miss; search() fell through to the in-memory store and returned empty for unloaded resources. SearchHelper.searchRepositoryByCanonicalWithPaging therefore failed to resolve, the visitor's tryResolveDependencyReadOnly got null, and recursion into base FHIR profiles was skipped. Added a search() override: on a miss with a url param, look up the URL in a new id index, call read() to warm the cache, then re-run the in-memory search.

3. DependencyRoleClassifier.isTransitiveKeyDependency version-asymmetric matching - stripped the version pin from the dependency reference on lookup but compared against a key set whose entries kept whatever pin the binding URL carried (FHIR core is inconsistent - publication-status|4.0.1 is pinned, library-type isn't). Added symmetric stripping (fast path for already-stripped entries, fallback scan otherwise) so set membership is URL-only and matches in either direction.

4. DataRequirementsVisitor.synthesizeMissingKeyDependencies - some key bindings live on slices of complex element types (e.g. Library.relatedArtifact:dependency.type -> related-artifact-type, where the binding is on the FHIR core RelatedArtifact complex type). The differential walk in StructureDefinitionAdapter.getDependencies() doesn't follow type.code into element types, so these never surfaced as deps. KeyElementAnalyzer correctly identifies them via the snapshot. Added a synthesizer step after the dep walk: any transitiveKeyCanonicals entry not already in the relatedArtifact list becomes a synthetic depends-on entry with role=key, populating cqf-resourceType and package-source from the conformance resolver.

5. enrichReference stub-CodeSystem version pin - once fix 2 made search() actually resolve stub CodeSystems (CodeSystem.content = not-present), external systems like SNOMED and LOINC picked up the stub's package-version field as a bogus pin (http://snomed.info/sct|3.2.1). Re-use the existing stub-detection signal (URL is in the resource-type index but excluded from the version index) at the enrichment point to return the bare URL for stubs and preserve the unversioned external-CodeSystem references the operation produced previously.

Test plan

• Canonicals self-referential URL regression test added
• NpmRepository search-by-URL behavior with and without packages
• DependencyRoleClassifier version normalization in both directions
• Full cqf-fhir-cr visitor test suite - 337 tests, no regressions
• Full cqf-fhir-utility test suite - no regressions
• spotlessCheck passes
• End-to-end verification against hl7.fhir.uv.cql 2.0.0 IG: 27/27 expected key ValueSets surface with crmi-dependencyRole=key
• Verify downstream consumer (VSP) sees external CodeSystems without version pins

[github-actions]

Formatting check succeeded!

[sonarqubecloud]

Quality Gate failed

Failed conditions
41.9% Coverage on New Code (required ≥ 80%)

See analysis details on SonarQube Cloud