Add logic for leader registrations

[stphnlee]

The workflow action had been created to find the registration group through the linkage on the registration instance; however, our leader groups are handled through connection requests and aren't linked directly through the registration instance. I added logic to identify if a groupmember hasn't been found through the normal linkage, then to check through the registration workflow which is how we link the leader registrants to their camp group.

[Copilot]

Pull request overview

This PR updates the SECC Registrations workflow action to better support “leader” registration scenarios where the person’s registration group membership is not linked through RegistrationRegistrant.GroupMemberId, but instead is inferred via the registration instance’s configured registration workflow type.

Changes:

• Adds a new optional action setting (WorkflowGroupAttributeKey) to provide a fallback lookup mechanism for leader registrants.
• Implements fallback logic that, when no linked registration group members are found, reads a WorkflowType-scoped workflow attribute (by key) to identify the registration group and locate the person’s GroupMember record.
• Introduces a helper method to resolve group membership from the registration instance’s RegistrationWorkflowTypeId configuration.

[gmcgrady]

Clarified the role of the WorkflowGroupAttributeKey w/ Stephen. Overall, the branch is solid & ready to merge! An alternative thought could have been to include another attribute on the action & workflow that designates which case (camper or leader) the workflow is associated with; that way, in lieu of waiting for the campers to not be found, we could jump directly to finding the group members for leaders. The alternative idea would only be possible if we can identify the case (camper or leader) at time of placement. That said, this PR more than achieves what we need. Approving & merging.