ingest: bundle ingestion script (pkg.tar.zst -> repo)

[oysteinkrog]

Summary

Adds scripts/ingest_bundle.py, replacing the manual "hand-copy bundle contents into FFmpeg/" seam that caused a past stale-binary accident.

Given a local mingw-w64-x86_64-ffmpeg-if-bundled-*.pkg.tar.zst (or --from-release <MINGW-packages tag>, downloaded via gh), the script extracts the MINGW64 bundled package payload (mingw64/{bin,include,lib,share}), runs sanity checks, prints an EOL-normalization-aware diff report against the committed FFmpeg/ tree, and only writes (clean-replace) with an explicit --apply flag. Default is dry-run/report-only.

FFmpeg/bin/x64/ investigation (mandatory pre-work per bead)

Confirmed via git history + code search that FFmpeg/bin/x64/ is not duplicate cruft -- it's a load-bearing legacy probe path:

• build/generate-bindings.ps1/.sh resolve <BinariesPath>/x64 and pass it to FFmpeg.AutoGen.CppSharpUnsafeGenerator via --bin.
• CliOptions.cs defaults FFmpegBinDir to <FFmpegDir>/bin/x64.
• FFmpeg.AutoGen.Example/FFmpegBinariesHelper.cs probes FFmpeg/bin/x64 at runtime for DynamicallyLoadedBindings.
• build/extract-ffmpeg.ps1 already reconstructs it (copies all *.dll from bin/ into bin/x64/) "for generator compatibility".

ingest_bundle.py reproduces this same reconstruction on every ingest, inheriting the ffplay.exe exclusion applied to top-level bin/ (see "What gets excluded" below for why SDL2/openal are not excluded here despite an earlier version of this PR treating them the same as ffplay.exe).

What gets excluded

ffplay.exe exists in upstream bundles but is intentionally not committed (PR #1) -- it isn't packed by FFmpeg.AutoGen.Redist and has no consumer in MotionCatalyst. The script drops it during ingest and reports it explicitly as "dropped during ingest" regardless of whether that produces a tree diff.

Update, post-review: this PR originally also dropped SDL2.dll/libopenal-1.dll alongside ffplay.exe, on PR #1's original premise that ffplay.exe was their only consumer. A regression agent (DESKTOP-12084) found that premise wrong: avdevice-if-61.dll, hard-imported by the packed ffmpeg.exe/ffprobe.exe, itself imports both SDL2.dll and libopenal-1.dll, so dropping them broke every spawned-exe code path with 0xC0000135. Narrowed the drop-list to {ffplay.exe} only, and removed the now-incorrect bin/x64 SDL2/openal special-casing that had been added alongside the original (wrong) trio-drop -- see "Bug caught during review" below for that part of the history. This PR is held pending a separate fix PR (restoring SDL2.dll/libopenal-1.dll to top-level bin/ and repackaging as Redist 7.1.3) landing first; see Deviations.

AC evidence

Ran the real script (dry-run, then --apply) against the actual committed mingw-w64-x86_64-ffmpeg-if-bundled-7.1-1-any.pkg.tar.zst.

Post scope-change (ffplay.exe-only drop-list), a fresh dry run against the still-current (pre-7.1.3) committed tree:

Extracting dummy.pkg.tar.zst...
Dropped during ingest (documented, PR #1 exclusion -- not packed by Redist, no consumer in MotionCatalyst): ffplay.exe
Running sanity checks...
  all sanity checks passed
Diffing against committed FFmpeg/ tree...

=== ingest diff report ===
  added:   2
  removed: 0
  changed: 0

-- added --
  + FFmpeg/bin/SDL2.dll (2.3MB)
  + FFmpeg/bin/libopenal-1.dll (1.9MB)

Exactly one documented skip (ffplay.exe), and SDL2.dll/libopenal-1.dll now correctly show as pending additions to the currently-stale committed bin/ tree -- consistent with the regression finding above. (bin/x64/ already carries both on master, unaffected by PR #1, which only ever touched top-level bin/.)

Earlier, pre-scope-change AC evidence (drop-list still included the trio, --apply run against the same bundle) showed the bin/x64 stale-copy cleanup described in the investigation section above:

Dropped during ingest (documented, PR #1 exclusion -- ffplay.exe's only consumer, not packed by Redist): SDL2.dll, ffplay.exe, libopenal-1.dll
=== ingest diff report ===
  added:   0
  removed: 2
  changed: 0

-- removed (documented: ffplay/SDL2/openal trio + stale bin/x64 copies) --
  - FFmpeg/bin/x64/SDL2.dll (2.3MB)
  - FFmpeg/bin/x64/libopenal-1.dll (1.9MB)

That --apply run's two deletions were subsequently reverted (commit d31002f) once the regression finding above showed those "stale" x64 copies were in fact still load-bearing.

Sanity checks verified against both a synthetic clean payload (built from the real committed, GPL-free binaries -- passes) and a doctored payload (avutil bytes patched to include --enable-libx264) -- correctly fails with avutil-if-59.dll build configuration contains '--enable-libx264' -- a GPL codec appears enabled and exit code 1, without touching FFmpeg/. The GPL check reads FFmpeg's own embedded ./configure string in avutil rather than naive cross-binary substring search, to avoid false positives from legitimate H.264 decoder-quirk strings, AVI/MOV fourcc tables, and CLI encoder-name tables that all contain x264/x265 bytes.

Extraction was verified via two independent, off-the-shelf paths (zstd CLI itself is not installed in the dev sandbox that produced this PR, see Deviations): a ctypes/libzstd streaming decompressor, and Windows' own built-in tar.exe (bsdtar 3.8.4 with bundled libzstd 1.5.7, extracts .tar.zst natively). Both produced byte-identical payloads (258 files, zero diff -rq deltas), and both independently reproduce the same ingest diff report above.

Bug caught during review: content-hash diffing is blind to file mode

The first real --apply run against the real bundle silently changed the mode bits on 186 unrelated files with zero content change: every file already committed under FFmpeg/ is 100755 uniformly (confirmed via git ls-tree), but the upstream bundle's own payload extracts at 644 for headers/libs, and shutil.copy2/copytree were preserving that. The diff logic (git hash-object on file content) never caught this, because git blob hashes don't encode file mode at all -- a mode-only change is invisible to any diff that only compares blob content. Caught by manually inspecting git diff --stat after --apply (it showed 186 "M" files with 0 insertions(+), 0 deletions(-), i.e. mode-only changes). Fixed by forcing 0o755 on all staged files before diff/apply, mirroring the tree's existing convention regardless of what the upstream payload ships. Re-verified zero mode churn after the fix, using both extraction paths above.

Deviations

• zstd CLI is not installed in the dev sandbox this PR was built in. The shipped extract_bundle() still correctly shells out to zstd -dc | tar -x per spec -- unchanged, untouched. Verification used the two alternate extraction paths described above (ctypes/libzstd harness, Windows tar.exe) purely to unblock AC testing; neither is part of the shipped script.
• Rebased onto if/master after PR scripts: redist verification script (quality gates) #2 (verify_redist.py/redist-manifest.txt, a parallel bead) merged -- no file overlap, clean rebase.
• Held pending a separate fix landing first: a fix restoring SDL2.dll/libopenal-1.dll to top-level bin/ and repackaging as Redist 7.1.3 (owned by a different agent/bead) needs to merge to master before this PR merges, so this PR's own AC evidence and this repo's master stay consistent about what's excluded. Will rebase onto that once it lands and re-confirm pack-and-verify is green before self-merging.

Test plan

• python3 -m py_compile scripts/ingest_bundle.py
• Dry-run against real committed bundle: report shows exactly one documented skip (ffplay.exe), SDL2.dll/libopenal-1.dll correctly reported as pending additions
• --apply against real bundle (pre-scope-change trio-drop list): working tree diff matched the dry-run report exactly, zero mode noise -- later reverted once the trio premise was found wrong for SDL2/openal
• Sanity checks pass on clean payload, fail correctly on doctored payload
• --apply refuses when undocumented removals are present (verified via code path + non-destructive dry-run reproduction of the warning)
• Verified via two independent extraction tools (ctypes/libzstd, Windows tar.exe) -- byte-identical payloads, identical ingest results

[oysteinkrog]

Additional verification, independent of the ctypes/libzstd harness mentioned above: extracted the real committed bundle using Windows' built-in tar.exe (bsdtar 3.8.4, bundled libzstd 1.5.7 -- handles .tar.zst natively, no separate zstd CLI needed) via cmd.exe /c "tar -xf <winpath> -C <winpath>". Byte-for-byte identical to the ctypes-extracted payload (258 files, zero diff -rq deltas). Running the ingest script's dry-run against this independently-extracted payload against the currently-applied worktree reports zero differences -- confirms the applied state is correct via a second, off-the-shelf extraction path.

WSL-side, zstd CLI is still not installed, so the shipped extract_bundle()'s actual zstd -dc | tar -x subprocess pipeline (as specced) hasn't had a live run yet in this environment -- both alternate extraction paths above exist only to unblock verification, not as changes to the script's own logic.