Fix the Jellyfin rename call: it takes a name, not an id

POST /Library/VirtualFolders/Name is the odd one out in that controller --
most of /Library/VirtualFolders/* takes an id, and passing one here returns
a bare "HTTP 400: Error processing request." that says nothing about why.
Verified against 10.11.4: name -> 204.

Also records that renaming re-ids the library, because Jellyfin derives the
ItemId from the name. ytstream is unaffected because find_library matches on
path -- confirmed by a full refresh-metadata over 257 NFOs with 0 proxy
requests straight after the rename.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

deploy/retire-jellyfin-library.py

@@ -143,9 +143,20 @@ def main() -> None:
         print(f"==> deleted {old['Name']!r}")
 
     if renaming:
+        # `name`, NOT `id`. This endpoint is the odd one out -- most of
+        # /Library/VirtualFolders/* takes an id, and passing one here returns a
+        # bare "HTTP 400: Error processing request." that says nothing about why.
+        # Verified against Jellyfin 10.11.4 on 2026-08-13: name -> 204.
         request(key, "POST", "/Library/VirtualFolders/Name",
-                {"id": new["ItemId"], "newName": FINAL_NAME})
-        print(f"==> renamed to {FINAL_NAME!r}")
+                {"name": new["Name"], "newName": FINAL_NAME})
+        print(f"==> renamed {new['Name']!r} to {FINAL_NAME!r}")
+        # A library's ItemId is derived from its name, so renaming re-ids it --
+        # measured, 98e74a0c… became 34f331a8…, which was the *deleted* library's
+        # id, because that one had this name. Nothing here caches an ItemId, and
+        # ytstream's own find_library() matches on path, so both survive it. Any
+        # future caller that stores an ItemId will not.
+        print("    note: the library's ItemId changed (Jellyfin derives it from "
+              "the name)")
 
     after = folders(key)
     print()