refactor(reader): the HTTP layer reads through queries and writes through the service

Feed, playlists, saved views, tags and the Home pins do no database work in their routes any more:
reads go through reader/queries (and feedquery for a feed page, its counts and facets), writes
through reader/service and discover/pins, which flush; the handlers commit. Reader is fenced below
its HTTP layer too: its owner filters go through userscope, and the catalog's jobs ask Reader
instead of joining its tables (the auto-tagger's system tags, the cleanup jobs' keep rule, the
maintenance notice). A playlist sync's catalog ingest moves to sync/videos.

backend/tests/test_playlist_merge.py

@@ -75,7 +75,7 @@ class TestMergePlan:
 
 class FakeYouTube:
     """Enough of YouTubeClient for merge_playlist: an in-memory playlist of (item_id, video_id)
-    and the write ops that mutate it. Every catalog video is pre-seeded so _ensure_videos never
+    and the write ops that mutate it. Every catalog video is pre-seeded so ensure_videos never
     needs get_videos."""
 
     def __init__(
@@ -89,7 +89,7 @@ class FakeYouTube:
         self.title = title
         self._seq = 0
         self.items = [(self._new_id(), v) for v in items]
-        # Ids the Data API won't return (private/deleted) — get_videos omits them, so _ensure_videos
+        # Ids the Data API won't return (private/deleted) — get_videos omits them, so ensure_videos
         # can't ingest them. They still live in the playlist (`items`) like a real un-ingestable video.
         self.unavailable = set(unavailable or ())
         # Ids whose add_playlist_item raises, to exercise the partial-failure baseline-hold path.