fix: name the error yt-dlp actually raises for a cookie-emptied client set

A review round read yt-dlp's source and found the comment behind the previous commit's safety-net
marker did not match it. Measured in the worker with a real account cookie and
`player_client=android_vr`: yt-dlp logs `Skipping client "android_vr" since it does not support
cookies`, drops it, and the request left with no client fails with "Requested format is not
available" — not "No player clients have been requested". That raise sits EARLIER in yt-dlp, before
the cookie-capability removal, so the cookie path can never reach it; and an unknown or renamed
client is skipped with a warning and replaced by yt-dlp's defaults, so the other scenario the
comment named cannot reach it either.

So the marker bought nothing: the symptom that does occur was already retriable here before this
branch. It is dropped, the comment now states what was measured, and the test asserts the real
symptom instead of a message the code cannot produce. The cookie-capability filter itself is
vindicated by the same measurement — without it every signed-in download would burn its first
attempt on a client yt-dlp discards.

Also from the round: an enqueue test for a `source_kind="youtube"` job, the one join nothing else
made (a YouTube job stores a bare 11-char ref and the URL the cookie gate keys on is rebuilt by the
adapter — both ends were pinned apart, the join was not, and a break there would stop every YouTube
cookie silently while signed-out downloads kept working). And copy corrections: the group's only
unhedged claim is hedged, "described the video" loses the pipeline vocabulary, and four Hungarian
phrasings that read as translated English are rewritten.

backend/app/downloads/adapters.py

@@ -93,10 +93,6 @@ class YouTubeAdapter(SourceAdapter):
         "Requested format is not available",
         "Only images are available",
         "Sign in to confirm",
-        # A set yt-dlp emptied because none of its clients take cookies. `client_sets` filters those
-        # out below, so this is the safety net for a yt-dlp that renames a client or an admin who
-        # configures both knobs with cookie-incapable clients only.
-        "No player clients have been requested",
         # Measured 2026-09-16: a gated video whose EXTRACTION succeeds and whose media fetch is then
         # refused by the CDN ("unable to download video data: HTTP Error 403"). The wall moves
         # between the player response and the stream, so this is the same per-client flakiness one
@@ -105,13 +101,15 @@ class YouTubeAdapter(SourceAdapter):
         # them, so the next client set is a real second chance.
         "unable to download video data",
     )
-    # Measured against yt-dlp's own INNERTUBE_CLIENTS table (2026-09-16, on 2026.07.04 and
-    # 2026.08.19): with account cookies attached yt-dlp REMOVES every client whose SUPPORTS_COOKIES
-    # is False, and a set left empty raises "No player clients have been requested". Our primary set
-    # is android_vr — one of those — so a signed-in download would fail on the first attempt and
-    # never reach the POT-backed web fallback that the cookie exists for. Pinned by test_adapters
-    # against the installed yt-dlp, so a version bump that moves the table turns the gate red
-    # instead of silently un-authing every YouTube download.
+    # Measured in the worker against a REAL account cookie (2026-09-16, yt-dlp 2026.07.04): with
+    # `player_client=android_vr` yt-dlp logs `Skipping client "android_vr" since it does not support
+    # cookies`, drops it, and the request that is left with no client fails with "Requested format is
+    # not available" — which is already a retriable marker above, so the cost is a wasted attempt
+    # rather than a hard failure. Our primary set is android_vr ALONE, so without this filter every
+    # signed-in download would burn its first attempt that way before reaching the POT-backed web
+    # fallback the cookie exists for. The list is yt-dlp's own INNERTUBE_CLIENTS[...]
+    # ["SUPPORTS_COOKIES"], pinned by test_adapters against the installed yt-dlp, so a version bump
+    # that moves the table turns the gate red instead of silently un-authing every YouTube download.
     _COOKIE_CAPABLE = frozenset(
         {
             "mweb",