fix(playlists): a push stops at a list deleted mid-way, and a rename made during it stays unsynced

A delete landing while a push read YouTube left a plan over no items, so the push emptied the
YouTube playlist a local-only delete keeps: the push now stops at a vanished list (PlaylistGone,
404), and a delete is refused while a sync of the list runs. The closing baseline fingerprints the
title YouTube got, not the one its lock re-reads, so a rename made during the writes stays dirty.
The other-tab test helper bounds its lock wait, so a lock-order regression fails instead of hanging.

backend/tests/test_playlist_sync_claim.py

@@ -67,7 +67,12 @@ def test_push_and_revert_refuse_while_the_list_is_claimed(
             r = c.post(f"/api/playlists/{pl.id}/{path}")
             assert r.status_code == 409
             assert r.json()["detail"] == {"code": "playlist", "reason": "sync_busy"}
+        # a delete too: a push mid-way would plan the deleted list as emptied (E28 round 4)
+        r = c.delete(f"/api/playlists/{pl.id}")
+        assert r.status_code == 409
+        assert r.json()["detail"] == {"code": "playlist", "reason": "sync_busy"}
     assert ran == []
+    assert db.get(Playlist, pl.id) is not None
 
     # Released on the way out: the same list syncs again, and a claim is per list.
     assert c.post(f"/api/playlists/{pl.id}/push").status_code == 200