fix(linux): verify the FFmpeg download against a pinned checksum

[thcp]

Fixes #518. Targets fix/516-drain-child-pipes -- last of the sequential Rust changes. Merge #529 first.

The problem

download_linux_ffmpeg fetched a tarball from a rolling URL on a single non-CDN host, extracted it with the system tar, marked the binaries executable and ran them -- with no integrity check of any kind.

• Windows verifies against BtbN's published checksums.sha256
• macOS verifies against four pinned hashes
• Linux verified nothing

verify_ffmpeg only proves the binary runs and has the encoders StemDeck needs. That says nothing about where it came from.

Why a pinned SHA256 rather than upstream's .md5

The obvious move was the .md5 companion, matching the Windows shape. I checked it and it is worth less than it looks:

• MD5 is broken for collisions
• The companion is served by the same host as the tarball. Anyone able to replace one can replace the other. It evidences corruption, not authenticity.
• Upstream publishes no .sha256 (confirmed: 404)

So this pins our own SHA256, the way the macOS path already does. The pinned value was computed from the artifact whose MD5 matched upstream's published 7fa72b652e19bf84c9461e332ea1cdf3, so the pin is anchored to what upstream currently vouches for.

url    .../ffmpeg-release-amd64-static.tar.xz   (last-modified 2024-08-24)
md5    7fa72b652e19bf84c9461e332ea1cdf3          (matches upstream)
sha256 abda8d77ce8309141f83ab8edf0596834087c52467f6badf376a6a2a4c87cf67

Trade-off: the URL is rolling, so this needs a manual bump when upstream publishes a new build. A stale pin fails closed with a checksum error rather than silently accepting whatever arrives, which is the right direction to fail. STEMDECK_FFMPEG_URL still overrides and skips the check -- an override points somewhere we cannot have a hash for, matching how the macOS override already behaves.

Verification -- and a gap reviewers should know about

This code cannot be compiled on macOS, and ci.yml does not build the Rust shell at all -- Linux Rust is compiled only by linux-release.yml, at release time. So a type error here would first surface during a release.

To check it locally I temporarily widened the cfg gate on the two constants and download_linux_ffmpeg from #[cfg(all(unix, not(target_os = "macos")))] to #[cfg(unix)] and ran cargo check:

error count: 0

Then restored all 7 gates (verified by count).

cargo fmt --check   OK
cargo clippy        0 errors
cargo test          59 passed, 1 failed (the known port flake, fails on base too)

Worth filing separately

There is no linux-check.yml. #421 added macos-check.yml and windows-check.yml precisely because ci.yml is 100% ubuntu and could not compile cfg-gated code for those platforms -- but nothing compiles the Linux Rust either, despite the runner being ubuntu. That is a real hole and it is what made this PR awkward to verify. Happy to open an issue.