TASK 48 item 1: bundle ffmpeg — the app no longer downloads an executable

Store policy 10.2.2 forbids dynamic code inclusion, and this was the only
third-party binary the app ever downloaded and ran. It had already failed in
production: the pin aged out of BtbN's 14-day retention and the download 404'd
on the creator's first real recording attempt (2026-09-01). Bundling kills
that failure class permanently and deletes the startup network dependency.

- scripts/fetch-ffmpeg.sh populates a gitignored ./ffmpeg from a pinned
  month-end BtbN LGPL-shared artifact, SHA-256 verified before extraction,
  idempotent, FFMPEG_ZIP= override. 135 MB of DLLs in git would tax every
  commit on this 9p tree; the URL + hash are the audit trail LGPL §6 wants.
- ytLive.csproj copies ffmpeg\** to output and publish (Always), and a
  GuardBundledFfmpeg target fails the BUILD if the folder is missing, so a
  fresh clone finds out before a take rather than during one.
- FfmpegLocator loses the downloader, the zip extraction and the
  %APPDATA%\ytLlive\tools cache. Order is now bundle -> PATH, deliberately
  inverted: a PATH ffmpeg may be a different major version or a GPL build,
  and the bundle is what was pinned, license-vetted and tested. A missing
  bundle throws loudly; the old "found something on disk" path could satisfy
  a missing bundle with a stale copy, and silent drift is the worst failure
  mode for a dependency certification inspects.
- ffplay.exe (18 MB) is not shipped; nothing calls it.
- THIRD-PARTY-NOTICES.txt: "downloads" -> "bundled" throughout, and the stale
  build tag autobuild-2026-08-09-13-03 — the tag that 404'd — corrected to
  autobuild-2026-08-31-13-27 with the exact artifact name and archive hash.
  OpenH264 made precise: compiled INTO avcodec-63.dll, no separate binary.

Checked whether other third-party binaries needed bundling: no. e_sqlite3.dll
and WebView2Loader.dll already ship via NuGet into runtimes\win-x64\native\,
OpenH264 is inside avcodec-63.dll, the rest are managed. Two gaps remain that
bundling cannot fix, recorded in the map: the WebView2 Evergreen runtime is a
machine prerequisite (TASK 48 item 2), and Velopack's updater downloads and
executes, so its teardown is a compliance action.

Tests: 16 locator facts, suite 379/379, 0 warnings. The integration test runs
the bundled ffmpeg -version, which is the only assertion that proves the
sibling libav*.dll resolved — presence checks pass with the DLLs missing and a
shared build then fails to start. TheLocatorCarriesNoNetworkCapability keeps
10.2.2 from rotting back.

Analysis: TASKS/research-store-certification.md §4.

MyMistakes.md

@@ -1266,3 +1266,51 @@ Two corollaries, both paid for here:
 **Generalisation: a memory map entry that makes the reader's *next action* wrong is a bug, not an
 omission.** When a fact is superseded by a ruling, the ruling wins the headline — the stale detail
 belongs underneath it, labelled as what it is.
+
+### Bundling a pinned binary: verify the pin, then delete the whole download path (TASK 48 item 1)
+
+FFmpeg was the app's only download-and-execute third-party binary, which is exactly what Store
+policy 10.2.2 names — and it had already failed in production (2026-09-01, the pin aged out of
+BtbN's 14-day retention and the download 404'd mid-task). Bundling it took one unit. Four things
+worth keeping, in the order I learned them:
+
+**1. Check whether you already have the bytes before you re-fetch them.** The creator's local
+`%APPDATA%\ytLlive\tools` already held the pinned build from the September download. Extracting the
+pinned zip fresh and comparing SHA-256 per file proved all 9 were byte-identical, which upgraded
+"probably the right build" to "provably the right build" for the price of one download. **An
+existing cache is a hypothesis, not a fact — but it is a cheap hypothesis to test, and testing it
+is what makes the bundle trustworthy.**
+
+**2. Flip the probe order and say why, in the code comment.** The locator probed PATH first
+("the user's own install wins"). Once the binaries are in the package, that is backwards: a PATH
+`ffmpeg` may be a different major version or a **GPL** build, and the bundle is the one you pinned,
+license-vetted and tested. PATH stays as the escape hatch, which is what it was actually for.
+I would not have caught this without asking "which of these two is the one I tested?"
+
+**3. Delete the fallback, do not just deprioritise it.** The old ladder had
+`PATH → tools-cache → download`, and the tools-cache step meant a **missing bundle could be
+silently satisfied by a stale copy**. For a dependency that Store certification inspects, silent
+drift is the failure mode you least want: the package is wrong and nothing says so. A missing
+bundle now throws, naming the folder and the fetch script. Likewise a build-time guard in the
+csproj, so a fresh clone learns before a take rather than during one.
+
+**4. 135 MB of DLLs in git is a real, recurring tax — the hash is the better audit trail.** The
+temptation is to commit the binaries so "the build just works". On a 9p-bridged working tree that
+tax is paid on *every* commit, status and checkout, forever, to serve a one-time packaging step.
+Shipping a `fetch-ffmpeg.sh` that pins the URL and **verifies SHA-256 before extracting** keeps
+the repo small, keeps the network dependency at build time instead of run time (which is what the
+policy actually forbids), and gives the LGPL written-offer something better to point at than an
+opaque blob: a URL, an artifact name, and a hash a reviewer can recompute.
+
+**The test that earned its keep:** the integration test runs the bundled `ffmpeg.exe -version`.
+Presence checks would all have passed with the DLLs missing — a shared build simply fails to
+start, so *executing* it is the only assertion that proves the `libav*.dll` siblings resolved. When
+a binary's correctness depends on its neighbours being adjacent, test the neighbours.
+
+**Also: check what you just claimed about the licences.** `THIRD-PARTY-NOTICES.txt` said OpenH264
+"ships inside the FFmpeg build". Verified rather than assumed: the encoder is compiled *into*
+`avcodec-63.dll` (8 references in that DLL) and there is no separate OpenH264 binary to ship — so
+the claim was right but imprecise, and it now says precisely that, with the check and its date.
+The same file was still naming build tag `autobuild-2026-08-09-13-03` — **the tag that 404'd.**
+A licence record that names a stale artifact is worse than no licence record, because it reads as
+verified. When you pin something, the pin and the paperwork must move in the same commit.