test(config-upgrade-snapshot): prove WAL-trim safety + add fault-injection seam for marker trigger

Confirmed task 5's existing 6 tests already satisfy "exactly once",
"safe under forced retry", and "does not re-home entities"; confirmed
test_snapshot_recv_old_format_version_rejected_fail_loud (task 1)
already covers format-mismatch rejection by proxy through
load_snapshot's two shared callers (network-install, boot replay).

Adds the two genuine gaps: (1)
test_marker_triggered_checkpoint_trim_preserves_standby_mid_catchup_segments
proves trim_wal_segments/repl_trim_lsn's standby-cursor retention
guard (bug-1147) still holds when reached via the new marker-triggered
checkpoint path, not just the old periodic/direct-call path -- guard
itself untouched. (2) persist_marker_checkpoint_fault_hook
(#ifdef XCE_TESTING, NULL default, true no-op in production) gates
whether persist_checkpoint_marker_triggered runs, for task 8.7's later
crash-before-checkpoint-durable injection; minimally proven here.
Task 8.1 of 19.

Requirements: 1.1, 1.5, 1.8, 5.2, 5.3, 5.6, 5.7, 6.3, 7.3, 7.4

.kiro/specs/config-upgrade-snapshot/tasks.md

@@ -78,7 +78,7 @@
   - _Depends: 5_
 
 - [ ] 8. Validation: regression coverage for every new mechanism
-- [ ] 8.1 (P) Unit-test the marker-apply trigger and its interaction with WAL retention
+- [x] 8.1 (P) Unit-test the marker-apply trigger and its interaction with WAL retention
   - Assert the configuration-marker case fires a checkpoint exactly once per apply and is safe under a forced retry
   - Assert the trigger does not itself re-home entities
   - Add a deterministic fault-injection seam at the marker-apply-to-checkpoint-durable boundary, mirroring the existing fault-hook pattern already used elsewhere in this codebase, for later chaotic-scenario use