fix(playlists): a refused edit is taken back on screen, and a gone list or tag is said, not swallowed

Deep-review round 4, the playlist surfaces.

- A failed move or reorder relied on the resync to put the rows back — but the server's list is
  unchanged, so the refetch comes back deep-equal, react-query keeps the same `data` object, and the
  re-seed effect keyed on it never ran: the moved row stayed gone, the rejected order stayed on
  screen. Both restore from the cached detail now.
- A failed removal puts its row back itself: when the server is unreachable the resync fails too,
  and round 3's "keep the list on a failed refetch" guard then kept showing it as removed.
- The Plex playlist page (remove / rename / delete / reorder), the add-to-playlist popover and the
  tag manager had no failure handling at all: a list or tag deleted elsewhere (a 404, now a
  structured `not_found` the request layer leaves to the caller) failed in silence and an
  optimistic removal stayed removed. Each says it and resyncs; deleting a Plex playlist that is
  already gone just leaves the page.
- Playlists' own loading/error branches use the shared `LoadingState` / `StateMessage` (the loading
  line had no live region).
- The "player stays mounted" tests count mounts: a remount ended with the same flag as staying up.

frontend/src/i18n/locales/en/plex.json

@@ -320,7 +320,11 @@
     "seasonUnknown": "Episodes",
     "addShow": "Add whole show to a playlist",
     "addSeason": "Add season to a playlist",
-    "addEpisode": "Add episode to a playlist"
+    "addEpisode": "Add episode to a playlist",
+    "removeFailed": "Couldn't remove it from the playlist.",
+    "renameFailed": "Couldn't rename the playlist.",
+    "deleteFailed": "Couldn't delete the playlist.",
+    "reorderFailed": "Couldn't save the new order."
   },
   "people": {
     "count_one": "{{count}} title",