forced-red harness used the PRODUCTION mountpoint and its cleanup trap umount+rmdir'd it - recovered, no data loss, needs mechanical isolation

NEAR-MISS, SELF-DISCLOSED, NO DATA LOST. Building a forced-red harness for the LUKS mount guard, nw-whey-cc used /media/rob/backupYes - the PRODUCTION mountpoint - as the harness's test mountpoint. The harness cleanup trap then ran umount + rmdir against it, which hit the REAL run #270 mount and deleted the real mountpoint directory. Caught immediately via cryptsetup status (mapper untouched, still active against /dev/sdc1), remounted, directory recreated, contents confirmed present. The mapper was never closed, which is the only reason this was recoverable. WHY THIS IS p1 AND NOT A NOTE. The harness exists to prove a backup guard works. It reached into the backup it is meant to protect, through its own CLEANUP path - the part that runs unconditionally, including on the error exits the harness is deliberately provoking. A harness that forces failures runs its trap more often than a normal script, so a trap pointed at production fires on exactly the runs the harness was written to produce. And the blast radius scales the wrong way: had the trap also closed the mapper, or had the umount landed while a backup was writing, this is data loss on the only offline copy of the fleet's backups. THE DEFECT IS SHARED IDENTITY, NOT A TYPO. Nothing distinguished the test mountpoint from the production one, so the correct command hit the wrong object. This is the same shape as the st_dev hole already ruled on this lane - a path that LOOKS like the destination is not the destination - and the same shape as trash-on-a-shared-mount: a correct primitive aimed at an object nobody re-checked. DELIVERABLE, MECHANISM NOT CARE: (1) the harness owns every object it touches - own backing file, own mapper name under a reserved test prefix, own mountpoint from mktemp -d, never a literal under /media; (2) every destructive site guarded with ${VAR:?} AND a refusal to act on any mapper name or path not matching the test prefix, so the guard fails closed rather than on the operator remembering; (3) the trap asserts what it is about to release belongs to this run before releasing it. Related and already open on this lane: the v2.1 mount guard itself, the run-ledger success-covers-body-not-teardown finding, and the st_dev anchor on leg 3.