fix(db): leave V56 untouched to avoid Flyway checksum drift (#684)

Editing an already-applied migration changes its Flyway checksum and would
fail validateOnMigrate against prod (where V56 is applied). Revert the V56
comment edit; V71 now records that it reverses V56's no-FK choice and points
to ADR-032 as the authoritative record, so the V56 -> V71 trail stays
discoverable without touching the applied migration. (DevOps review, PR #736.)

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

backend/src/main/resources/db/migration/V56__add_transcription_block_mentioned_persons.sql

@@ -8,13 +8,12 @@
 -- all blocks mentioning person X" query on the person detail page joins on
 -- the indexed person_id column — equally fast as JSONB GIN containment, no
 -- new dependency. document_comments.comment_mentions stays as a many-to-many
--- to AppUser; the divergence is intentional.
+-- to AppUser; the divergence is intentional: Person mentions need lazy
+-- degradation when a person is deleted (no FK), while user mentions don't.
 --
--- person_id FK: added in V71 with ON DELETE CASCADE (this column was originally
--- created without a FK — that decision was reversed). The literal "@Name" in
--- transcription_blocks.text keeps the name visible after a person is deleted;
--- the sidecar row carries only the link and is removed with the person, so the
--- read renderer degrades to plain unlinked text. See ADR-032.
+-- No FK on person_id: when a Person is deleted we want @Auguste Raddatz to
+-- remain visible as plain unlinked text inside the transcription rather than
+-- vanishing or cascade-deleting the block.
 
 CREATE TABLE transcription_block_mentioned_persons (
     block_id      UUID          NOT NULL REFERENCES transcription_blocks(id) ON DELETE CASCADE,

backend/src/main/resources/db/migration/V71__person_delete_on_delete_fk.sql

@@ -32,6 +32,9 @@ ALTER TABLE public.document_receivers
 
 -- Soft reference fix: transcription_block_mentioned_persons.person_id was a UUID with no FK
 -- (V56), so deleting a person left dangling mention rows. Give it a real FK with CASCADE.
+-- This reverses V56's deliberate "no FK on person_id" choice — that comment is now historical
+-- but is intentionally left untouched, because editing an already-applied migration changes its
+-- Flyway checksum and would fail validateOnMigrate in prod. ADR-032 is the authoritative record.
 -- Clean up pre-existing orphans first — production likely holds dangling rows because the old
 -- deletePerson never cleaned mention rows, and the ADD CONSTRAINT validation scan fails on them.
 -- A DO block with RAISE NOTICE surfaces the purge count: Flyway runs each statement via JDBC