fix: bundle a JS engine so Made-for-Kids videos download at full quality

[ThorSPB]

The report

Feedback #17, from the church PC (v1.6.0): a link pasted into Others
failed with ERROR: [youtube] Mg1Aa34cHjI: This video is not available — while
the same video plays fine in a browser. The church PC's own log matches a Pi
reproduction line for line.

Root cause

The app shipped no JavaScript engine.

yt-dlp solves YouTube's signature / n challenge by running YouTube's own
JavaScript, which needs a JS engine on the machine — and yt-dlp auto-enables
only deno. The church PC has no deno, node, bun or qjs anywhere (where
finds none).

Videos that demand the challenge release no adaptive-format URL until it is
solved. I parsed the player response directly: all 24 adaptive formats up to
1080p60 are listed, every one with url=no. Adaptive formats are the only route
above 360p (the sole surviving muxed format is 360p), so all of them get
dropped, yt-dlp falls through its client list, visionos answers UNPLAYABLE,
and YouTube's flatly wrong reason string is passed through verbatim.

The discriminator is YouTube's "Made for Kids" flag

Swept 22 videos, no engine vs --js-runtimes quickjs:

set	no engine	with qjs
Cocomelon ×2, Baby Shark ×2, Mount Moriah ×3, God's Joy Kids, Listener Kids, Hi Heaven, KidSpring	all 8 FAIL	all 1080p (one 4K)
10 non-kids — Sabbath-school channels, sermons, Romanian karaoke, Rick Astley, Big Buck Bunny	fine, 720p–4K	identical

8/8 kids fail, 0/10 non-kids fail. Not channel-, age- or category-bound:
failures span five unrelated channels and 2021/2026 uploads, all
People & Blogs, isFamilySafe: true in both groups. Confirmed by comments
being force-disabled (a hard COPPA consequence creators cannot override) on 4/4
failing and 0/3 working. isMadeForKids is absent from both the web and android
player responses, so the flag cannot be read directly.

That is why nothing had ever failed before: an ordinary video is served by
visionos with clean URLs and never needs JavaScript at all.

The fix

quickjs-ng publishes static single-file builds of ~2 MB, fetched per
platform in release.yml (pinned by QUICKJS_TAG) into
app/tools/quickjs_<platform>/ — which the spec already bundles wholesale, so
no spec change. config.py resolves it into js_runtime_path, recomputed on
every load_settings() like mpv_path/ffmpeg_path.

A missing engine stays silent rather than adding a user-facing warning: it
is not exposed in Settings, a source checkout legitimately has none, and an
empty path just means "let yt-dlp auto-detect" — the old behaviour.
download_video logs which engine it used instead, so a build that shipped
without the binary, or lost its executable bit in packaging, shows up in the log
rather than quietly reverting to 360p-or-nothing.

The player-client retry (first commit) stays as a safety net behind the
engine: it rescues such a video at 360p where the engine gets 1080p, which still
matters if the binary is missing or broken, and for whatever YouTube does next.

Verification

Through the app's own download_video, binary placed exactly where a build puts
it:

	result
before	first attempt fails; retry rescues it at 640x360 h264+aac, 3.43 MB
after	succeeds on the first attempt — 1920x1080 av1+opus, 7.27 MB, no retry

Both weekly channel videos pick 399+251 with and without the engine, so
nothing about the Sabbath downloads changes. 303 passed. The new config tests
were mutation-checked (breaking the Windows path, and adding a warning on a
missing engine, each fail the intended test).

Notes

• ⚠ js_runtimes must be a dict of {runtime: {config}}. A list raises a
  bare ValueError from YoutubeDL.__init__ that names no option.
• ⚠ yt-dlp auto-enables only deno. Node can sit on PATH completely unused,
  which is what makes "no JS runtime" so easy to misdiagnose — it briefly fooled
  me into thinking the yt-dlp version mattered.
• Dead ends, all measured: PO tokens are irrelevant (a real GVS token was
  minted, nothing changed); forcing player_client=web is SABR-only
  regardless, which sends you chasing yt-dlp #12482; upgrading yt-dlp
  changes nothing (stable 2026.08.19 == nightly 2026.08.30); the android
  client alone "works" but serves only muxed 360p — a trap that looks like a fix.
• Merging: this PR's title carries no bump tag, so a squash merge cuts no
  release (same as fix: ship the app icon at every size Windows asks for #31). The second commit's subject has none either; the first
  one's does.

🤖 Generated with Claude Code