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/Plex.md

@@ -86,7 +86,12 @@ root runs as the `dank` user, and the deployer adopts the data root with
 4. **Cold container boot is slow.** PMS pre-binds 32400 and empty-replies
    while the HTTP layer finishes loading; the first boot of a years-old
    library took ~10 minutes (2026-09 cutover). The deployer gate now allows
-   600 s before failing; later boots are much faster (warm page cache).
+   600 s before failing; later boots are much faster (warm page cache). A
+   `systemctl --user start` issued after an `unmask` is a job in the manager,
+   not in the shell that issued it: it lands minutes later and survives that
+   client dying, so a wrapper script that looks hung is usually only waiting —
+   read `is-active` and `podman ps` before declaring a fault, and give every
+   step of such a script its own `timeout`.
 5. **`32400` answers TLS only to remote clients.** PMS requires secure
    connections, so `curl http://192.168.0.235:32400/identity` from any other
    machine closes without a single byte (curl exit 52) — that reads as a dead
@@ -131,10 +136,13 @@ shred -u /tmp/px.tok
 ```
 
 Every section answers `204` — or `200` with a Directory body when
-`Accept: application/json` is sent. Inside the quoted `printf` format a
-backslash-newline is LITERAL, not a continuation, so `mk` writes two `printf`s:
-one glued line and one stray backslash is a config file curl rejects, and the
-failure prints as `option -K: is unknown`, never as a bad config line.
+`Accept: application/json` is sent. A refresh fired while PMS is still warming
+answers `000` instead (the empty reply of gotcha 4, arriving mid-request): retry
+until it answers and never restart the service over it. Inside the quoted
+`printf` format a backslash-newline is LITERAL, not a continuation, so `mk`
+writes two `printf`s: one glued line and one stray backslash is a config file
+curl rejects, and the failure prints as `option -K: is unknown`, never as a bad
+config line.
 
 Proof that a rename landed is not a scan response: `scripts/media-verify.py`
 replays the run's journal against the database — the only read that