feat(playlists): act on the selected rows from the toolbar, and undo either

While rows are selected the toolbar's second row is the band: the count,
the last target as one click, Move to, Remove, Clear selection. Both write
in one request and undo back to the places; a video the target held before
stays there. Delete takes the selection when there is one. A failure puts
the rows back ticked.

A row's own move goes through the same write, so it undoes too, and the
single-row move route and service function are gone. A playlist row drops
its grip below a 24rem table: the row menu keeps the moves.

backend/app/routes/playlists.py

@@ -421,44 +421,6 @@ def remove_item(
     return {"ok": True, "playlist_id": pl.id, "video_id": video_id}
 
 
-class MoveItemIn(BaseModel):
-    target_playlist_id: int
-
-
-@router.post("/{playlist_id}/items/{video_id}/move")
-def move_item(
-    playlist_id: int,
-    video_id: str,
-    body: MoveItemIn,
-    user: User = Depends(current_user),
-    db: Session = Depends(get_db),
-) -> dict:
-    """Move one video from a playlist into another of the caller's playlists, atomically.
-
-    ONE transaction on purpose. The obvious client-side shape — add to the target, then remove
-    from the source — leaves the video in BOTH lists whenever the second call fails, which is
-    exactly the kind of half-applied state this codebase treats as a bug rather than an edge
-    case. Idempotent: if the video is already in the target, the source row is simply dropped
-    (moving into a list that already has it is a removal, not a duplicate)."""
-    src = _own_playlist(db, user, playlist_id)
-    # Its own reason: "this playlist doesn't exist any more" about a TARGET that is gone was read as
-    # the list on screen — which is still there.
-    dst = queries.own_playlist(db, user, body.target_playlist_id)
-    if dst is None:
-        raise not_found("move_target")
-    try:
-        service.move_item(db, src, dst, video_id)
-    except service.MoveRefused as e:
-        # A same-list move is a bad request; a video a concurrent edit (another tab, a YouTube
-        # re-pull) already took out is gone.
-        status = 400 if e.reason == "same_playlist" else 404
-        raise HTTPException(
-            status_code=status, detail={"code": "playlist_move", "reason": e.reason}
-        ) from None
-    db.commit()
-    return {"ok": True, "from_playlist_id": src.id, "to_playlist_id": dst.id, "video_id": video_id}
-
-
 class VideoIdsIn(BaseModel):
     video_ids: list[str] = []
 
@@ -542,8 +504,13 @@ def move_items(
     user: User = Depends(current_user),
     db: Session = Depends(get_db),
 ) -> dict:
-    """Move many videos into another of the caller's playlists, in one transaction, for the reason
-    `move_item` gives. Says which landed there and which it already held, for the "Undo"."""
+    """Move videos into another of the caller's playlists, atomically.
+
+    ONE transaction on purpose. The obvious client-side shape — add to the target, then remove
+    from the source — leaves a video in BOTH lists whenever the second call fails. A video the
+    target already has only leaves the source, and one a concurrent edit (another tab, a YouTube
+    re-pull) already took out is skipped. Says which landed there and which it already held, for
+    the "Undo"."""
     src = _own_playlist(db, user, playlist_id)
     dst = _other_list(db, user, body.target_playlist_id)
     try: