fix: pin retained Linux FFmpeg build and monitor asset availability

[Kaileshwar16]

Fixes #521.

HFlow's managed Linux FFmpeg pin pointed at a mid-month BtbN daily autobuild:

autobuild-2026-08-16-13-00

That asset was pruned under BtbN's retention policy, so a fresh Linux setup could hit HTTP 404 before the first video operation.

This repins HFlow to the retained August month-final build:

autobuild-2026-08-31-13-27
n8.1.2-50-g1a748fe2cd

Both x86_64 and aarch64 archives were downloaded directly and their SHA256 values were calculated locally before updating the pin.

Retention and availability

The old SHA256 pin guaranteed the identity of the downloaded bytes, but not that the upstream asset would continue to exist.

The comment next to the pin and CONTRIBUTING.md now document that future pins should be selected from the last successful build of a completed month rather than an arbitrary daily autobuild.

I kept this as documented policy rather than enforcing the calendar date in a unit test, since BtbN's actual retention property is the last successful build of the month, not necessarily something that can be proven safely from the tag date alone.

Detecting future expiry

Added an opt-in availability test for both pinned Linux architectures:

test_pinned_release_assets_available

It:

• checks both x86_64 and aarch64
• follows GitHub release redirects
• uses HTTP HEAD, so the archives are not downloaded
• reports the architecture and URL when a pin is unavailable

The check now runs in two places:

• weekly via .github/workflows/pinned-assets.yml, with manual dispatch support
• immediately before distributions are built in the publish workflow

This means a disappeared pin can be noticed while the project is otherwise idle, and a release will also refuse to publish with unavailable managed FFmpeg assets.

Managed download validation

The existing real-download test now clears both FFmpeg overrides and uses an isolated cache, so it validates a genuinely fresh managed installation rather than succeeding from an existing cache or system binary.

The new x86_64 pin successfully:

• downloaded from the pinned URL
• passed SHA256 verification
• extracted ffmpeg and ffprobe
• resolved both managed binaries
• executed successfully

Observed versions:

ffmpeg version n8.1.2-50-g1a748fe2cd-20260831
ffprobe version n8.1.2-50-g1a748fe2cd-20260831

The aarch64 archive was also downloaded, hashed and inspected separately. It contains the expected executable ffmpeg and ffprobe binaries for AArch64.

Pipeline identity

TRANSFORM_BEHAVIOR_VERSION is bumped from 7 to 8.

Changing the managed FFmpeg version changes the provenance of transcoded canonical output, so those outputs should not share the previous pipeline identity.

Behavior unchanged

The existing FFmpeg resolution policy is preserved:

• HFLOW_FFMPEG remains the explicit override
• HFLOW_FFPROBE behavior is unchanged
• Linux still uses the pinned/checksum-verified managed build by default
• there is still no silent PATH fallback on Linux
• SHA256 verification remains mandatory
• ffmpeg and ffprobe are installed together
• cache/reuse behavior is unchanged
• WSL2 continues following the Linux path
• macOS/native Windows fallback behavior is unchanged

Validation

uv sync --locked --all-extras                  passed
uv run ruff check                              passed
uv run ruff format --check                     passed
uv run ty check                                passed

offline FFmpeg tests                           77 passed, 4 skipped
network availability check                     2 passed
fresh managed download/network validation      3 passed
Python 3.11 FFmpeg network suite               80 passed, 1 skipped
full test suite                                1,940 passed, 9 skipped

workflow YAML/config checks                    passed
git diff --check                               passed

The normal full suite uses system FFmpeg through conftest, so the separate network runs were used to validate the managed provisioning path directly.

[kstonekuan]

LGTM, merging.

Checksum verified here independently: c733b4b2...b4d2b for linux64.

The TRANSFORM_BEHAVIOR_VERSION bump is what #525 was missing. compute_pipeline_version does not hash ffmpeg_version, so without it the two encoder builds share one pipeline identity.

Reverting the bump passes every test, and that is correct rather than a gap: it declares that bytes may differ, which no test can observe.