docs(jellyfin): episode stills are out of scope, and the cost that says so

A per-episode RemoteImages query is never cached, so the same campaign that
dressed 620 series in an afternoon costs ~11 s per episode for one hit in five.
Across 42k episodes that is days of provider traffic to dress a fifth of them, and
clients show series and season art regardless. Recorded so nobody runs the pass on
a hunch; the door and the resumable log are the same if Frank orders it.

serverAppConfigs-docs/Dankserver/Jellyfin.md

@@ -119,6 +119,24 @@ store on a build where the automatic image pass will not run at all — it is ho
 the Movies library got its art: 2,515 of 2,564 films carry a primary now, and the
 rest have none in TMDb (shorts like `Astartes`, files whose names match nothing).
 
+**The Download door's exact wire shape:** the list response carries the address in
+`Url` — there is no `ImageUrl` field — and the POST takes camelCase query params,
+`?type=Primary&imageUrl=<Url>`, answering `204`; the stored tag then appears in
+`ImageTags`. PascalCase params, or an `imageUrl` left empty, answer `500`, which
+reads as a server fault and is a field-name fault.
+
+**`RemoteImages` answers empty for an item with no `ProviderIds`** — no provider id,
+nothing to look up. Art coverage is capped by identification, not by the image door:
+the items a campaign returns nothing for are the unidentified ones, and no image
+retry will change that.
+
+**Series and season art is fetched; episode stills are not, deliberately.** Every
+episode query is a fresh provider round-trip — nothing caches per episode — measured
+at ~11 s per item beside ~2 s per series on the same host, with one hit in five in a
+sample. Across 42k episodes that is days of provider traffic to dress a fifth of them,
+and clients display the series and season art anyway. If episode stills are ever
+ordered, the loop is the same door and its log makes the pass resumable.
+
 **API shape on 12.x:** `/Items` and `/Items/{id}` need `UserId` when
 authenticated by API key — without it the answer is `400 Error processing
 request`, which reads exactly like an authentication failure. `MetadataRefreshMode`
@@ -284,12 +302,24 @@ anything. The fix is `systemctl --user restart jellyfin.service`, one POST after
 health answers, and then believe `ScheduledTasks` State at 130 % CPU, not the
 response code.
 
-**A scan that must see a new folder has to be recursive.** `POST /Library/Refresh`
-is the incremental pass, and inotify does not cross a rootless podman bind, so
-folders created on the host stay invisible to it. The move is
-`POST /Items/{id}/Refresh?Recursive=true` (204) per library, the id from
-`GET /Library/VirtualFolders` — its field is `ItemId`, not `Id` — and that same
-record's `RefreshStatus` is the progress read.
+**The door that scans is `POST /Library/Refresh` (204), and `ScheduledTasks` is the
+progress read.** Measured 2026-11-02 against a `Shows` library that had never been
+identified: the per-library `POST /Items/{id}/Refresh?Recursive=true` answers `204`
+and queues **nothing** — item census identical afterwards, `Scan Media Library`
+idle, journal silent — and it is still an empty `204` after a service restart, so
+that status code carries no information at all. `/Library/Refresh` walks every
+library; within seconds the journal names folders (`…/TVShows/…`,
+`EpisodeMetadataService`) and `GET /ScheduledTasks` reports
+`Scan Media Library | Running | 75 %` while the process sits near 200 % CPU.
+
+**`RefreshStatus` on the `GET /Library/VirtualFolders` record is not a progress
+read.** It stayed `Idle` through a scan that was verifiably running at 75 %. The
+record's useful field is `ItemId`, and the live library set is still the entries
+whose `Locations` are non-empty.
+
+`inotify` does not cross a rootless podman bind, so folders created on the host
+stay invisible until a pass like this runs; every pass that writes into a library
+ends by firing one.
 
 **`Movies` has no watcher at all.** `EnableRealtimeMonitor` is per library (table in
 *Data layout*) and it is false for `Movies` and `Collections`. Nothing notices a