fix(r5): address the seventh /code-review high round — 7 findings

Five of them sit where round 6 turned F from a Fullscreen API call into a CSS
maximise: the guards around it still asked `isFullscreen`, which that pivot made
permanently false.

- Arrow-key volume was dead in the maximised view: the scroll-deference checked
  only `isFullscreenRef`, so the (now hidden but still scrollable) card kept
  swallowing Up/Down. Both flags now count as "the video fills the screen".
  Measured: 87px of scroll room on the focused card, ArrowDown moves 80 -> 75
  and scrolls nothing.
- The maximised view had no way out once the pointer touched the video. Reaching
  YouTube's controls means clicking into the cross-origin iframe, which takes
  keyboard focus with it, and the re-arm paths (stage mouseleave, window focus)
  need the pointer to leave the browser entirely while the stage fills it. So
  the exit now lives on screen, in our DOM: a button that un-maximises AND pulls
  focus back, re-arming every shortcut.
- WebKit fires only `webkitfullscreenchange`/`webkitFullscreenElement`, so on
  Safari/iPadOS YouTube's own fullscreen never registered — no overlay yield, no
  focus reclaim. One `fullscreenEl()` reader, both event spellings.
- The stage claimed `z-index: 9999`, the glass tuner's reserved level, for a job
  that only needs to beat the modal chrome it is nested in (its siblings top out
  at z-menu). Dropped to rail-level; nothing escapes the modal's stacking
  context either way.
- `inset: 0` already sizes a fixed layer — the inherited `100vw`/`100vh`
  over-constrained it, which is how a classic scrollbar gets a horizontal
  overflow and a mobile URL bar hides the bottom edge (YouTube's control bar).
- The shortcut hint still promised "F: fullscreen" in both locales.

Backend, both "the fix stopped one layer short":
- The startup HLS sweep was awaited inside lifespan, so uvicorn still served
  nothing until it finished — a thread doesn't help when nothing is listening
  yet. Fire-and-forget task instead, cancelled on shutdown. Measured with 200
  planted segments: "Application startup complete" now precedes "swept 1".
- An RSS poll where every channel failed returned normally, so the scheduler
  recorded `ok` with the outage buried in the summary string. `failed == total`
  now raises: a run that reached nothing is a failed run.

Suites: backend 147 -> 150.

backend/app/sync/runner.py

@@ -56,7 +56,11 @@ def run_rss_poll(db: Session, channels: list[Channel] | None = None) -> dict[str
 
     `failed` counts a channel whose feed could not be READ *or* whose rows could not be APPLIED —
     both leave the channel un-polled, and counting only the first would move the blind spot rather
-    than remove it."""
+    than remove it.
+
+    Raises RuntimeError when NOTHING could be polled (`failed == total`, total > 0): a run that
+    achieved literally nothing is a failed run, and only an exception turns the scheduler card red
+    — a returned count leaves it green with the outage buried in the summary line."""
     if channels is None:
         channels = db.execute(select(Channel)).scalars().all()
     total = len(channels)
@@ -99,6 +103,12 @@ def run_rss_poll(db: Session, channels: list[Channel] | None = None) -> dict[str
             progress.report(done, total, "rss_poll")
     if failed:
         log.warning("RSS poll: %d/%d channels could not be polled", failed, total)
+    if total and failed == total:
+        # Nothing was polled at all — an egress outage (the tinyproxy-after-reboot incident), a
+        # dead DNS, a read-only database. Returning normally would record the run as `ok` with the
+        # failure hidden inside the result string, i.e. a green pill for a total outage; the count
+        # in the message keeps the summary just as informative.
+        raise RuntimeError(f"RSS poll failed for all {total} channels")
     return {"new": new, "failed": failed}