Merge pull request 'docs(jellyfin): the switches live under LibraryOptions; a pinned art pass is not a provider census' (#124) from feat/jellyfin-provider-keys into main

serverAppConfigs-docs/Dankserver/Jellyfin.md

@@ -81,10 +81,13 @@ so an empty `<ImageFetchers />` switches art off while `ImageFetcherOrder` stays
 fully populated — order is not enablement — and the populated `<MetadataFetchers>`
 built next to it makes the library look healthy.
 
-**Live posture, measured 2026-11-02** from `GET /Library/VirtualFolders`. The DTO is
-PascalCase — `Name`, `CollectionType`, `Locations`, `ItemId`, `RefreshStatus` — and a
-census written against the 10.x camelCase keys reads `None` for everything, which
-looks exactly like an unconfigured library.
+**Live posture, measured 2026-11-02** from `GET /Library/VirtualFolders`, cross-checked
+against each library's `config/root/default/<Library>/options.xml`. The switches are NOT
+top-level DTO keys: the folder carries `Name`, `CollectionType`, `Locations`, `ItemId`,
+`PrimaryImageItemId`, `RefreshStatus` and `LibraryOptions`, and every per-library option
+sits inside `LibraryOptions`. Reading `EnableInternetProviders` off the folder itself
+answers `None` for all four — the camelCase trap one level deeper, and it looks exactly
+like an unconfigured library.
 
 | Library | `CollectionType` | `EnableInternetProviders` | `EnableRealtimeMonitor` |
 |---|---|---|---|
@@ -133,14 +136,17 @@ nothing to look up. Art coverage is capped by identification, not by the image d
 the items a campaign returns nothing for are the unidentified ones, and no image
 retry will change that.
 
-**A `Download` campaign over a library that is already dressed does nothing in
-seconds, and that is the measurement proving identification is the only lever
-left.** Run over all 753 series and 2,805 seasons of `Shows` on 2026-11-02 it
-classified 3,558 items in 20 s: 2,908 already carried a primary, 624 have no
-provider id at all, 26 have an id and no poster in TMDb — zero downloads. The
-artless remainder is not an image-door problem: it is the unnamed long tail (clip
-collections, `(Warhammer TV)`-shaped directories), and the lever is folder names
-or an identify pass, never another retry loop.
+**A `Download` pass reports zero only when it is pinned to one provider.** A TMDb-pinned
+campaign over `Shows` classified every item in 20 s, downloaded nothing, and concluded that
+identification was the only lever left. The same door queried with no `Providers=` filter
+answered for 16 seasons that same day — every offer from `TheTVDB`, which the pinned form
+never asks — and all 16 are dressed now. A pinned answer proves one provider is empty; the
+unpinned answer is the provider census, and a TV art loop that pins is simply the wrong tool.
+Post-fill the artless remainder measures 86 items (80 seasons, 6 series): 61 carry no provider
+id at all — the unnamed long tail (`3a BBW - Series (2010-11)`, `History Of Africa With Zeinab
+Badawi`, `(Warhammer TV)`-shaped directories), where the lever is folder names or an identify
+pass — and 25 hold an id and draw no offer from any provider. No image retry moves either
+group, which is the half of the old conclusion that survives.
 
 **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
@@ -149,9 +155,11 @@ sample. Across 42k episodes that is days of provider traffic to dress a fifth of
 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`
+**API shape on 12.x:** `/Items/{id}` needs `UserId` when authenticated by API key — without
+it the answer is `400 Error processing request`, which reads exactly like an authentication
+failure, and it bites hardest as a *verification* read directly after a write that succeeded.
+The `/Items` list route, `?Ids=<id>` included, needs no `UserId`, so verify writes there.
+`MetadataRefreshMode`
 accepts `Default` (and `Realtime`) only; `Full` and `ValidationFailure` are
 rejected outright, and what forces the providers to re-run is
 `ReplaceAllMetadata=true`.