feat(e10): make "move a video to another list" one atomic request

The one-step move S2 needs has no honest client-side shape: "add to the target, then
remove from the source" leaves the video in BOTH lists whenever the second call fails,
and the reverse order loses it entirely. So it is one endpoint in one transaction —
POST /api/playlists/{id}/items/{video_id}/move — which re-parents the existing item row
(so `added_at` survives), recomputes `dirty` on both sides, and is idempotent when the
target already holds the video.

Also publishes `updated_at` on the playlist summary, and bumps it explicitly for the
edits that only write `playlist_items` (add / remove / reorder / move). UpdatedAtMixin's
`onupdate` fires on an UPDATE of the playlist row, so without `_touch` the rail's coming
"recently changed" sort would have seen renames and nothing else.

backend/app/routes/playlists.py

@@ -3,6 +3,8 @@ CRUD (create / rename / delete, add / remove / reorder items) plus YouTube two-w
 mirror the user's own YouTube playlists in (`/sync-youtube`) and push/revert local edits back
 out (`/{id}/push-plan`, `/{id}/revert-youtube`), behind the optional write scope."""
 
+from datetime import datetime, timezone
+
 from fastapi import APIRouter, Depends, HTTPException
 from pydantic import BaseModel
 from sqlalchemy import func, select, and_
@@ -52,6 +54,16 @@ def _own_playlist(db: Session, user: User, playlist_id: int) -> Playlist:
     return pl
 
 
+def _touch(pl: Playlist) -> None:
+    """Bump the playlist's `updated_at` for an edit that only writes `playlist_items`.
+
+    `UpdatedAtMixin`'s `onupdate` fires on an UPDATE of the PLAYLIST row, and add / remove /
+    reorder / move write the item rows instead — so without this the rail's "recently changed"
+    sort would only ever see renames. The assignment is what makes the column mean "last time
+    this list changed", which is what the rail promises the reader."""
+    pl.updated_at = datetime.now(timezone.utc)
+
+
 def _next_playlist_position(db: Session, user_id: int) -> int:
     """Append position for a new playlist in this user's rail."""
     return (
@@ -91,6 +103,7 @@ def _add_item(db: Session, pl: Playlist, video_id: str, *, mark_dirty: bool) ->
     )
     if mark_dirty:
         recompute_dirty(db, pl)
+    _touch(pl)
     db.commit()
     return True
 
@@ -108,6 +121,7 @@ def _remove_item(db: Session, pl: Playlist, video_id: str, *, mark_dirty: bool)
     db.delete(item)
     if mark_dirty:
         recompute_dirty(db, pl)
+    _touch(pl)
     db.commit()
     return True
 
@@ -129,6 +143,9 @@ def _summary(
         "item_count": count,
         "total_duration_seconds": total_duration,
         "cover_thumbnail": cover,
+        # When this list last CHANGED (rename, add/remove/move/reorder) — the rail's
+        # "recently changed first" sort reads it. See _touch for why it isn't automatic.
+        "updated_at": pl.updated_at,
     }
     if has_video is not None:
         out["has_video"] = has_video
@@ -520,6 +537,63 @@ def remove_item(
     return {"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)
+    dst = _own_playlist(db, user, body.target_playlist_id)
+    if src.id == dst.id:
+        raise HTTPException(
+            status_code=400, detail={"code": "playlist_move", "reason": "same_playlist"}
+        )
+    item = db.scalar(
+        select(PlaylistItem).where(
+            PlaylistItem.playlist_id == src.id, PlaylistItem.video_id == video_id
+        )
+    )
+    if item is None:
+        # A concurrent edit (another tab, or a YouTube re-pull) already took it out.
+        raise HTTPException(
+            status_code=404, detail={"code": "playlist_move", "reason": "not_in_playlist"}
+        )
+    already = db.scalar(
+        select(PlaylistItem).where(
+            PlaylistItem.playlist_id == dst.id, PlaylistItem.video_id == video_id
+        )
+    )
+    if already is not None:
+        db.delete(item)  # the uq_playlist_video constraint would reject a second row anyway
+    else:
+        # Re-parent the existing row rather than delete+insert: `added_at` ("when I saved this")
+        # survives the move, and there is no window where the video belongs to neither list.
+        item.playlist_id = dst.id
+        item.position = _next_item_position(db, dst.id)
+    # Both sides changed, so both get the dirty recompute and the timestamp — the asymmetric
+    # version of this (touching only the source) is the recurring smell CLAUDE.md warns about.
+    recompute_dirty(db, src)
+    recompute_dirty(db, dst)
+    _touch(src)
+    _touch(dst)
+    db.commit()
+    return {"ok": True, "from_playlist_id": src.id, "to_playlist_id": dst.id, "video_id": video_id}
+
+
 class ReorderItemsIn(BaseModel):
     video_ids: list[str] = []
 
@@ -555,5 +629,6 @@ def reorder_items(
         it.position = pos
         pos += 1
     recompute_dirty(db, pl)
+    _touch(pl)
     db.commit()
     return {"playlist_id": pl.id, "count": pos}