BEFORE  sha256: c5414f24426a4a0050becadeb564990465bf48772a7cb029daaebd22ef788441
BEFORE  line 1536: 1	ORIGINAL-VALUE-A	2026-08-22 15:34:22.455005+02
AFTER   line 1536: 1	ALTERED-VALUE-B	2026-08-22 15:34:22.455005+02
AFTER   sha256: 834c32b19b9ec053b2909f031751cbbcf8d14941b5af2fdf1f3779b113b82d36
occurrences of ORIGINAL-VALUE-A left in the scratch dump: 0
occurrences of ALTERED-VALUE-B: 1
--- the volume tar still holds the ORIGINAL (it is the other candidate):
-rw-r--r-- 1 root root 53301760 Aug 22 14:01 /mnt/felhom-drives/hdd_1/backups/offsite-restore/docmost/mnt/sys_drive/felhom-data/backups/primary/docmost/db-dumps/../volume-dumps/docmost_docmost_postgres_data.tar

THE THREE-WAY DISCRIMINATOR, set up before the reconstitution:
  live database now holds : LIVE-VALUE-C3      <- if this survives, NEITHER leg wrote
  volume tar holds        : ORIGINAL-VALUE-A   <- if this wins, the volume tar supplied the state
  altered SQL dump holds  : ALTERED-VALUE-B    <- if this wins, the dump supplied it (as the comment intends)

FENCE: the mutation was applied to the PREPARED SCRATCH ONLY. The off-site store and the live
recovery unit were not touched. Proved after the run by re-preparing a fresh scratch from the same
snapshot and confirming it still reads ORIGINAL-VALUE-A.
