fix: prevent duplicate parameter resolution for %subject, %encounter and %practitioner in InputParameterResolver

[not-mksv]

Background

When a PlanDefinition is $apply-ed, input parameters referenced in ActivityDefinition dynamicValue expressions are resolved twice - once at the PlanDefinition level and again at the ActivityDefinition level. This produces duplicate parameter values, which causes expressions like%encounter.period.start to fail silently.

Root cause

• The PlanDefinition's InputParameterResolver reads the input resource from the server and stores it (e.g. as %encounter).
• toActivityRequest() in ProcessDefinition.java passes the already-resolved parameters to the ActivityDefinition's ApplyRequest.
• The ActivityDefinition's InputParameterResolver copies the existing params and fetches the resource again, creating a duplicate entry for the same parameter.

Fix

Guard the %subject / %encounter / %practitioner blocks in InputParameterResolver.resolveParameters so the resolver only fetches when the parameter isn't already present in the passed-in baseParameters.

Test

Added testResolveParametersSkipsRefetchWhenAlreadyInBaseParametersR4 in InputParametersTest. It seeds baseParameters with all three keys plus matching IDs, then asserts the result has exactly 3 parameters and no duplicates.