toFHIR cache key normalization in followedBy list mappings can overwrite repeated values (currently visible on HumanName.given)

[SevKohler]

Body

Summary

In toFHIR conversion, repeated openEHR values can be overwritten instead of appended when mapping through followedBy + list handling.
A narrow workaround is currently in place for HumanName.given, but the underlying cache-key strategy is still inconsistent and should be fixed generically.

Affected area

src/main/java/com/medblocks/openfhir/tofhir/IntermediateCacheProcessing.java
Method: handlePopulationWhereParentAndList(...)

Current behavior

• During cache population for list mappings, keys are normalized in a way that can collapse parent/list and child/single-item contexts.
• Subsequent lookups may resolve to a cached child StringType instead of the intended list container.
• Result: repeated values are overwritten (last value wins) instead of appended.

Example symptom

• PersonToFHIRTest#assertToFHIR_1 fails with:
  entry[0].resource.name[0].given[]: Expected 2 values but got 1
  when the .given workaround is removed.

Why this matters

This is not just a given problem; it indicates a general cache matching/key-normalization issue in followedBy/list flows.
A broad fix can affect many mappings (e.g. laboratory/report structures), so it needs a controlled refactor with regression coverage.

Temporary workaround in code

A targeted branch keeps full FHIR path for .given to avoid overwrite.
This is intentionally narrow and should be replaced by a generic solution.

Expected behavior

• Repeated openEHR entries must append to repeating FHIR fields reliably.
• Cache resolution should consistently return the correct parent/list target for followedBy list mappings.
• No mapping-specific path hacks should be required.

Proposed long-term fix

• Redesign cache key strategy for followedBy/list mappings:

1. Separate list-container keys from child/single-item keys explicitly.
2. Apply consistent normalization rules (including where(...)) across populate + lookup.
3. Use deterministic match selection based on structural specificity, not ambiguous prefix overlap.
4. Add regression tests for repeated fields (given, address lines, lab result lists, etc.).

Acceptance criteria

1. HumanName.given with multiple openEHR entries maps to multiple FHIR entries without path-specific hacks.
2. Existing person/lab/fall test suites continue to pass.
3. No mapping-file changes required for this behavior.