Prevent orphaned CE referrals when deleting enrollments

[gigxz]

Merging this PR

• use the squash-merge strategy for PRs targeting a release-X branch
• use a merge-commit or rebase strategy for PRs targeting the stable branch

Description

Prevent orphaned CE referrals when deleting enrollments

Problem

When an Enrollment with outgoing CE referrals was destroyed, the referrals were left with a source_enrollment_id pointing to a non-existent enrollment. This caused issues:

• Direct referrals: Lost their association to the source project, making them invisible on the source project's outgoing referrals list (they would "float" without context)
• Waitlist referrals: Could function without a source enrollment, but leaving orphaned references was inconsistent

Solution

Implemented custom before_destroy hooks that handle referrals based on their origin and status:

1. Active direct referrals prevent deletion: Enrollments with active (initialized/in_progress) direct referrals cannot be deleted, preserving the source project context. This forces the user to deal with the situation by closing those referrals
2. Completed direct referrals are destroyed: When deletion is allowed, all direct referrals are destroyed since they require the source enrollment to identify the sending project
3. Waitlist referrals are nullified: Waitlist referrals have their source_enrollment_id set to NULL since they can exist without the source enrollment context

Also added validation requiring source_enrollment_id for direct referrals to prevent creating orphaned direct referrals.

Alternatives Considered

Considered simpler approaches for the referral relation on Enrollment, I couldn't square any of these:

1. dependent: :nullify Problem: Works for waitlist referrals, but direct referrals become orphaned. The sending project loses visibility of the referral on their outgoing referrals list (though it remains visible on the receiving project's incoming referrals list).

2. dependent: :restrict_with_exception Problem: Prevents deletion of any enrollment that has ever been tied to a referral, even if the referral is completed. This is too restrictive and prevents necessary cleanup.

3. dependent: :destroy Problem: Might unintentionally delete legitimate referrals in waitlist-based scenarios where referrals should persist even if the source enrollment is removed.

Type of change

Bug fix

Checklist before requesting review

• I have performed a self-review of my code
• I have run the code that is being changed under ideal conditions, and it doesn't fail
• If adding a new endpoint / exposing data in a new way, I have:
  • ensured the API can't leak data from other data sources
  • ensured this does not introduce N+1s
  • ensured permissions and visibility checks are performed in the right places
• Any major architectural changes are supported by an approved ADR (Architectural Decision Record)
• I have updated the documentation (or not applicable)
• I have added spec tests (or not applicable)
• I have provided testing instructions in this PR or the related issue (or not applicable)

//: # NOTE: system tests may fail if there is no branch on the hmis-frontend that matches the Source or Target branch of this PR. This is expected

[gigxz]

This prevents the deletion, but the descriptive message doesn't make its way to the end-user (yet)

[gigxz]

needs ticket: support changing/adding source enrollment to referral

[gigxz]

not as compelling, revisit this one.. its more about the target project no?

[gigxz]

To do - add handling for destroying target enrollment