docs: the deep-backfill card counts the backlog, not the next pass

Two reviewers in a row read the admin card's selection against `run_deep_backfill`'s, saw it was
missing the job's `recent_synced_at` filter, and called it a card that counts channels the job will
never touch. It is the opposite: the card is the same backlog figure /api/sync/my-status shows the
user, and a channel still missing its recent pull is one the same job tick fetches first. Narrowing
it would hide genuinely queued work. Written down where the next reader will look.

backend/app/routes/scheduler.py

@@ -145,6 +145,10 @@ def get_scheduler(_: User = Depends(admin_user), db: Session = Depends(get_db))
             .where(Channel.recent_synced_at.is_(None), followed_channel())
         )
         or 0,
+        # The whole opted-in BACKLOG, deliberately not `run_deep_backfill`'s next-pass selection
+        # (which also wants `recent_synced_at`): the same figure /api/sync/my-status shows the user,
+        # and a channel missing its recent pull is one the same job tick fetches first, not one the
+        # job will never touch. Narrowing it here would under-report work that is genuinely queued.
         "channels_deep_pending": deep_eta["channels_pending"],
         "deep_eta_seconds": deep_eta["eta_seconds"],
         "videos_pending_enrich": db.scalar(