docs(media): the Plex leg ran, and a script fed over stdin owns that stdin

The 2026-11-01 morning leg cleared every Plex row naming a held path, so the prune page records the outcome plus the residue that is normal: a section pass rewrites feature rows first and can leave rows for clips in a film's other/ or extras/ folder standing after the 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 or the database.

Plex gains the two operational laws the run taught: a start job issued after an unmask belongs to the manager, not the shell, and lands minutes later surviving the client that issued it; a refresh fired while PMS is warming answers 000, so retry it rather than restart the service.

The trap that made a finished job look hung belongs to the remote job runner: a script fed to bash -s IS the stdin, so any child that reads stdin (podman exec -i) swallows the rest of the script without a word.

serverAppConfigs-docs/Dankserver/Media Duplicate Prune.md

@@ -106,11 +106,12 @@ cross it as inotify events. Scan in the order the rescan law sets — Jellyfin t
 `Idle`, then Plex's Movies section alone, one accepted refresh each; the requests
 are owned by [[Jellyfin]] and [[Plex]].
 
-As of 2026-11-01 the Plex leg is deliberately deferred: Plex is stopped and
-**masked** (`systemctl --user stop plex && systemctl --user mask plex`) so its
-metadata fetches cannot stack on Jellyfin's live scan, and a masked unit stays
-stopped through a reboot — `unmask` before starting it. Its Movies section (key 1)
-holds ~187 rows naming held paths until that one refresh is accepted.
+The Plex leg may be deferred on purpose: stop **and mask** Plex (`systemctl --user
+stop plex && systemctl --user mask plex`) so its metadata fetches cannot stack on a
+live Jellyfin scan, and because a masked unit stays stopped through a reboot —
+`unmask` before starting it. The 2026-11-01 morning ran it once Jellyfin reached
+`Idle`: one accepted `refresh` on the Movies section cleared every row that named a
+held path.
 
 The same evening's detritus pass is a second, separate hold: 423 files (12 MiB) in
 `/mnt/entropy/.AGENTTRASH/20261101-detritus-sweep`, plan `detritus-sweep-plan.tsv`,
@@ -126,6 +127,12 @@ extension the census does not recognise is a reason to stop, not to sweep.
 verdict is `still at src: 0` with `REAL: 0`, and the rows that simply vanished
 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.
+
 ## Failure signatures
 
 | Symptom | Meaning |