fix(ffmpeg): pin a month-final BtbN build and notice the next expiry

[mulkakhileshmj]

Closes #521.

Problem

The pinned Linux build was autobuild-2026-08-16-13-00, a mid-month daily. BtbN retains the last ~14 dailies plus each month's final build (kept two years), so the pin 404ed about a fortnight after it was chosen, and every fresh Linux install failed before its first video operation. CI installs the distro binary, so nothing we watch saw it.

The pin

Moved to autobuild-2026-08-31-13-27, the month-final closest to the expired pin, version label n8.1.2-50-g1a748fe2cd. Both checksums were computed from downloads performed for this change, not taken from a release page:

c733b4b2951e5957e15505f788b2c65a7a41b6da4b289e295852cc38079b4d2b  linux64-gpl-8.1.tar.xz
ae5da4f51b9052390f414005f8ab26c1eed1268f327cce7cb79aa076b29bd66e  linuxarm64-gpl-8.1.tar.xz

The extracted x86_64 binary reports ffmpeg version n8.1.2-50-g1a748fe2cd-20260831, so the existing PINNED_VERSION_LABEL in version_line assertions hold. The comment above the pin now states the retention rule alongside the immutability one, since immutable was true and was not the property that failed.

The two decisions, answered

Enforced, not remembered. test_pinned_release_tag_is_a_month_final_build is an offline test refusing any pin whose tag date is not the last calendar day of its month. The evidence for that exact rule: every surviving month-final on the release list (2026-02 through 2026-08, February's 28th included) falls on the last calendar day. The honest edge: BtbN's real rule is "last build of the month", so if a month-end build is ever skipped, the true month-final lands a day early and the test refuses a correct pin. That false refusal is deliberate and the docstring says so: it forces whoever updates the pin to re-verify retention rather than trust the tag's shape, which is the failure direction an availability property wants.

Noticed before a user finds it. Two parts. test_pinned_urls_are_reachable HEADs every pinned URL on the existing HFLOW_NETWORK_TESTS=1 gate, cheap enough to run anywhere. And a new scheduled workflow (.github/workflows/pinned-assets.yml, weekly plus manual dispatch) runs exactly that test and the month-final check, so an expiry becomes a red run instead of a fresh install's 404. Weekly is load-bearing: dailies live fourteen days, so a wrongly pinned daily is caught while the asset is still downloadable and the fix is a calm re-pin rather than an archaeology exercise. The workflow reuses ci.yml's pinned action SHAs; it is the "needs someone to actually run it" trade-off resolved by having the schedule be the someone.

Validation

Run on WSL2 Ubuntu, Python 3.12:

uv sync --locked
uv run ruff check          # All checks passed
uv run ruff format --check # already formatted
uv run ty check            # All checks passed
uv run pytest -q           # 1924 passed, 7 skipped
HFLOW_NETWORK_TESTS=1 uv run pytest -q tests/test_ffmpeg.py -k "reachable or real_pinned"

The network run performed the real end-to-end proof against a cleared cache: both HEADs return 200, the full download verifies against the new checksums, extracts, and the installed ffmpeg and ffprobe both report the pinned label. Mutation: re-pinning to the current daily autobuild-2026-09-12-13-12 turns the month-final test red with the message explaining the retention trap; restored, green.

🤖 Generated with Claude Code

[kstonekuan]

Resolved in #526.

It bumped TRANSFORM_BEHAVIOR_VERSION; yours did not. compute_pipeline_version does not hash ffmpeg_version, so without it the old and new encoder builds share one pipeline identity.