fix(e24): the review's three backend defects — blocklist, shelf order, next episode

The resume rail built its own SELECT instead of going through `filtered_query` and copied
only three of its predicates, so it dropped the per-user channel blocklist the module
docstring claims it inherits. Blocking a channel never touches `video_states`, so a
half-watched video from it kept its resume position and headed the rail — and, at the
default budget with the resume tier leading, became the landing page's hero: the app
answering "what should I watch" with the thing the user had just banned. The clause is now
`feedquery.not_blocked_cond`, shared with `filtered_query` rather than copied a second
time; the feed's SCOPE clauses stay deliberately unapplied, for the reason `yt_video_row`
already gives.

`next_position` returned the shelf's row COUNT while nothing ever renumbers positions —
`remove_pin` deletes, and every FK cascade removes a pin when its target disappears. Past
the first hole the count under-counts, so a new pin landed in the middle of the shelf and,
past the second, on a position another pin already held. `max(position) + 1`, the idiom
`routes/playlists` already uses.

`next_episode` took the FIRST in-progress episode in broadcast order while `plex.rollup`,
which drives the show page's Resume button, takes the last. One show therefore had two
different "continue watching" answers, with the Home tile ranking it by its most recent
touch and then offering the episode abandoned weeks earlier. The new test asserts the two
implementations against each other rather than against a literal.

All three mutation-checked: each new test goes red for the defect it names.

backend/app/feedquery.py

@@ -117,6 +117,19 @@ def tags_by_category(db: Session, tag_ids: list[int]) -> dict[str, list[int]]:
     return out
 
 
+def not_blocked_cond(user: User):
+    """Per-user channel blocklist: never show this user videos from a channel they blocked
+    (applies to feed, Library, explore, the channel page and the Home resume rail alike).
+
+    A shared expression rather than a clause each surface writes for itself. Blocking does not touch
+    `video_states`, so a half-watched video from a newly blocked channel survives with its resume
+    position — and the one query that copied only PART of this predicate set is exactly how that
+    video came back as the landing page's suggestion after the user had said "never again"."""
+    return Video.channel_id.notin_(
+        select(BlockedChannel.channel_id).where(BlockedChannel.user_id == user.id)
+    )
+
+
 def filtered_query(
     db: Session,
     user: User,
@@ -207,13 +220,7 @@ def filtered_query(
         )
     )
 
-    # Per-user channel blocklist: never show this user videos from a channel they blocked
-    # (applies to feed, Library, explore, and the channel page alike).
-    query = query.where(
-        Video.channel_id.notin_(
-            select(BlockedChannel.channel_id).where(BlockedChannel.user_id == user.id)
-        )
-    )
+    query = query.where(not_blocked_cond(user))
 
     # Source filter. In the shared Library ("all" scope) it uses the GLOBAL via_search flag
     # (search-discovered by anyone). In "my" scope it's the user's OWN provenance: