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/Operations/Remote Job Runner.md

@@ -107,6 +107,12 @@ job.sh watch                     # refreshing status table
   `ssh 'bash -c "python3 -c \"…\""'` quoting broke repeatedly (unterminated
   quotes; `grep -c` returning `"0\n0"` because `|| echo 0` appended a line)
   every failure disappeared once the script was a file.
+- **A script fed over stdin owns that stdin.** `ssh host 'bash -s' <<'EOS'` hands
+  the script itself to stdin, so any child that reads stdin — `podman exec -i`,
+  `ssh -t`, a bare `read` — swallows everything after it and the remainder
+  vanishes without a word. It reads exactly like a hang: the commands before the
+  child print, the ones after never existed. Drop `-i`, or give every child
+  `< /dev/null`.
 
 ## Verify before trusting it (3am law)