docs(media): the array's write doors, and why survivors are re-verified by size

A folder-rename pass ran on the media array with no journal anywhere: no
jsonl on the array, no bash history, no cron/timer/job artifact, no other
host ever authenticating. The door was GNOME Files mounting the array over
SFTP (gvfsd-sftp -> sftp-server as dank): rename() with no shell and no
journal, bumping only the renamed directory's ctime. Copyparty cannot do
this (its bind is ro at the mount) and the *arr stack has no route to the
array at all (no SMB, no NFS, mini asleep).

Two laws fall out for the prune pipeline: re-verify survivors by size
rather than by the path a stale artifact recorded, and Plex extras rows
naming a held path survive a second section pass.

serverAppConfigs-docs/Dankserver/Media Duplicate Prune.md

@@ -97,6 +97,12 @@ keeper is missing — either one drops the whole group rather than half-applying
 - The 2026-11-01 pass held 226 files (~1.1 TiB) in
   `/mnt/entropy/.AGENTTRASH/20261101-duplicate-prune`, journals
   `dup-prune-exact.jsonl` and `dup-prune-similar.jsonl`. Purge pending Frank's word.
+- **Re-verify each survivor by size, not by the recorded path, before purging.**
+  Detection artifacts and plans key on paths, and a folder renamed by an
+  interactive session ([[Entropy Volume]], *Write doors*) makes its keeper look
+  deleted while it sits untouched under the new name. The 2026-11-01 audit hit
+  three such groups: every keeper was present, same bytes, different folder. A
+  purge decided from the plan's paths alone would have reported survivors gone.
 
 ## After the pass
 
@@ -129,9 +135,10 @@ from the database are the pass succeeding.
 
 One residue is normal, so do not chase it: a section pass rewrites the feature rows
 first, and rows for clips in a film's `other/` or `extras/` subfolder can still name
-a held path after the section's `refreshing` flag is back to `0`. Beside `REAL: 0`
-that is a dead disc-menu clip — not a false prune, and no reason to touch the cache,
-the database, or the hold.
+a held path after the section's `refreshing` flag is back to `0` — and a second
+section pass does not clear them either, so do not run one hoping for `0`. Beside
+`REAL: 0` that is a dead disc-menu clip — not a false prune, and no reason to touch
+the cache, the database, or the hold.
 
 ## Failure signatures