Filter unversioned canonical refs from $package expansion parameters

[c-schuler]

Summary

Manifests can carry expansion parameters whose values are unversioned canonical URLs (e.g. system-version=http://snomed.info/sct or canonicalVersion=http://example.org/ValueSet/foo with no |version pin). Most terminology servers reject expansions when system-version / canonicalVersion entries lack a pin. The expansion would be non-deterministic so the resulting $package call fails for the entire manifest instead of just the offending entries.

Add a guard in PackageVisitor.handleValueSets: after copying the manifest's cqf-expansionParameters into the working params adapter, drop any entry whose value is a canonical URL without a version pin. Each dropped entry produces a logger.warn with the param name and value so authors can see which entries need pinning. Non-canonical-valued params (booleans, codes like displayLanguage, language tags, etc.) pass through unchanged.

The persisted manifest in the repository is untouched - the filter applies only to the in-memory copy used for Tx expansion and the manifest copy included in the response bundle. This keeps $package idempotent on stored state.

Test plan

• Unit test: mixed-input case - unversioned http:// canonical dropped, unversioned urn:oid: canonical dropped, versioned http canonical kept, versioned urn canonical kept, language code + boolean kept
• Unit test: defensive null / empty-params inputs don't throw
• Full cqf-fhir-cr PackageVisitor test suite - no regressions
• End-to-end verification against a real manifest in jpaserver-starter - $package completes; warnings appear for unversioned entries; Tx server no longer errors

[github-actions]

Formatting check succeeded!

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
87.1% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud