fix(channels): address R14 deep-review findings

- Make the immediate-backfill guard SYMMETRIC: run_deep_backfill now also
  registers the channel it pages in _backfill_in_progress, so it and
  backfill_channel_now mutually exclude per-channel and never advance the
  same cursor concurrently (whichever started first). The interactive cap
  moves to a separate _immediate_running counter so the scheduler's channels
  don't false-trip it.
- Attribute the immediate backfill's spend: wrap it in
  quota.attribute(user_id, VIDEOS_BACKFILL_FULL) (route passes user.id), so
  it shows under the user's full-backfill action, not the OTHER/system bucket.
- Tests: the update_channel->background-task wiring + the demo guard
  (scheduled for a real user, NOT for demo); distinct N/S/L counts (2 short
  + 1 live) so a short/live swap fails; extracted channelDetailPollMs with a
  pure unit test of the poll-or-stop predicate.
- a11y: role="img" on the fully-synced charm so screen readers announce it.

backend/app/routes/channels.py

@@ -477,7 +477,7 @@ def update_channel(
     # request returns right away; the channel page's live poll shows the count climb. The scheduler
     # still finishes a very large channel's tail on its normal runs (deep_requested stays set).
     if deep_turned_on:
-        background.add_task(backfill_channel_now, channel_id)
+        background.add_task(backfill_channel_now, channel_id, user.id)
 
     return {
         "id": channel_id,