test(person): describe DB-cascade mechanism in delete service-path test (#684)

The deletePerson service-path guard (AC-4) is unchanged behaviourally, but its
comments described the removed reassignSenderToNull/deleteReceiverReferences
chain. Update them to the V71 ON DELETE cascade mechanism.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

backend/src/test/java/org/raddatz/familienarchiv/person/PersonServiceIntegrationTest.java

@@ -180,9 +180,9 @@ class PersonServiceIntegrationTest {
     @Test
     void deletePerson_detachesSentAndReceivedReferences_beforeDelete_noOrphan() {
         // A person referenced as BOTH a document sender and a document receiver must delete
-        // cleanly: deletePerson nulls the sender_id FK and removes the receiver join row first
-        // (reassignSenderToNull → deleteReceiverReferences → deleteById), so no FK orphan and
-        // the documents themselves survive.
+        // cleanly via the service path: deletePerson just calls deleteById, and V71's ON DELETE
+        // constraints null the sender_id FK and drop the receiver join row, so there is no FK
+        // orphan and the documents themselves survive.
         Person target = personRepository.save(Person.builder()
                 .firstName("Weg").lastName("Person").provisional(true).build());
         Person bystander = personRepository.save(Person.builder()
@@ -196,16 +196,16 @@ class PersonServiceIntegrationTest {
                 .status(DocumentStatus.UPLOADED).sender(bystander)
                 .receivers(new java.util.HashSet<>(Set.of(target))).build());
 
-        // Persist the fixture and detach everything so the native @Modifying deletes operate on
-        // the database directly without the persistence context holding stale references that
-        // would re-flush a now-deleted person as a transient association.
+        // Persist the fixture and detach everything so the delete operates on the database
+        // directly without the persistence context holding stale references.
         entityManager.flush();
         entityManager.clear();
 
         personService.deletePerson(target.getId());
 
-        // Native @Modifying queries bypass the persistence context — clear it so the asserting
-        // reads observe the post-delete database state, not stale managed entities.
+        // The ON DELETE cascade fires beneath Hibernate — flush the delete and clear the L1
+        // cache so the asserting reads observe the post-delete database state, not stale
+        // managed entities (the EAGER @ElementCollection on receivers makes this load-bearing).
         entityManager.flush();
         entityManager.clear();