fix(plex): an accepted reorder refetches the detail it just wrote

`commit`'s success handler writes the dragged list into the detail cache — round 6's fix, so a
re-entry inside the 30s staleTime renders the accepted order without a request — but then invalidated
only the LIST key, while the YouTube sibling it cites invalidates both. `next` is the membership of
the render that started the drag, and `reorder_playlist` only touches the rating_keys it is handed,
so it never ratifies that list: anything that landed meanwhile was clobbered by the write with
nothing scheduled to correct it. `commit` sets no busy flag either, so a removal really can complete
while a reorder is in flight, and with staleTime 30s and refetchOnWindowFocus off the phantom row
stayed on screen for as long as the view was mounted — and the next drag persisted an order built
from it.

Round 6's test had to be re-pointed, because it was written in a world with no refetch: its mock
answered the pre-reorder order forever, which a server that just accepted the write cannot do. It now
holds the refetch open instead, so it still pins what round 6 actually fixed — the cache is right
WITHOUT waiting for a request — and would fail if the write were deleted. Both halves are
mutation-checked against each other.

frontend/src/components/PlexPlaylistView.tsx

@@ -437,6 +437,13 @@ export default function PlexPlaylistView({
         qc.setQueryData<{ items: PlexCard[] }>(qk.plexPlaylist(playlistId), (old) =>
           old ? { ...old, items: next } : old,
         );
+        qc.invalidateQueries({ queryKey: qk.plexPlaylist(playlistId) });
+        // …and then REFETCH it, exactly as the sibling does. `next` is this render's membership, and
+        // the server only reorders the keys it was given — so anything that landed meanwhile (a row
+        // removed from another surface, an item added elsewhere) is clobbered by that write. With
+        // only the list key invalidated nothing corrected it: staleTime is 30 s and
+        // refetchOnWindowFocus is off, so the wrong membership stayed on screen for as long as the
+        // view was mounted and the next drag persisted an order built from it (round 7).
         qc.invalidateQueries({ queryKey: qk.plexPlaylists() });
       })
       .catch((e: unknown) => {