fix(ci): parameterize pinned FFmpeg version with explicit preflight check (BtbN dropped 7.1)

[santhiprakash]

Closes #13164.

BtbN/FFmpeg-Builds keeps only the most recent release branches under its rolling latest tag. The 7.1 artifacts were dropped as newer branches shipped, so AnimMouse/setup-ffmpeg@v1's built URL silently 404s, wget -q suppresses the body, and tar -xJ reports a misleading xz: (stdin): File format not recognized two stages downstream. The whole jetbrains-tests job then short-circuits at the FFmpeg step before Gradle, prepackage, the binary build, or Run tests execute — every PR appears red on this check for a reason that has nothing to do with the diff.

This PR does two things on .github/actions/run-jetbrains-tests/action.yml:

1. Parameterize the pin. Adds a ffmpeg-version input (default "8.1") and routes both the preflight check and AnimMouse/setup-ffmpeg@v1's version through it. When BtbN drops 8.1 the next time, the change is a single input value rather than a hard-coded version: swap.

2. Preflight-check the artifact. Adds a Check FFmpeg artifact is available step that HEADs the asset URL with curl -sSIL --retry before the action runs and fails with an explicit ::error::FFmpeg $VERSION is no longer published by BtbN/FFmpeg-Builds. Bump ffmpeg-version. Missing: $url annotation when the asset is missing or unreachable. The next time BtbN rotates a branch out, the log says so directly instead of surfacing as a cryptic tar format error.

The 8.1 default was verified against BtbN's latest tag at PR time: the URL https://github.com/BtbN/FFmpeg-Builds/releases/download/latest/ffmpeg-n8.1-latest-linux64-gpl-8.1.tar.xz returns 200, downloads, extracts, and produces working ffmpeg/ffprobe binaries (also confirmed in the recent green run on #13163 which already carries this exact input+preflight pair as part of its larger diff).

Test plan

• Pre-flighted the BtbN URL with curl HEAD: 200 OK.
• Triggered fresh CI run via follow-up commit; verify preflight passes, FFmpeg downloads, all downstream steps execute.
• Verify jetbrains-tests outcome on the fresh run.

Note on the autocomplete test failure

The first push of this PR (commit f0d8a029d) showed jetbrains-tests failing at extensions/intellij/src/testIntegration/.../Autocomplete.kt:42 (assertTrue(text.contains("TEST_LLM_RESPONSE_0"))) instead of at the FFmpeg step — i.e. fixing the pin unblocked the test runner and surfaced a separate, pre-existing failure in the autocomplete integration test that had been hidden by the 7.1 404 since 2026-08-19T22:00Z. That failure appears tied to other code changes also being carried by #13163 (which is the last PR observed with a green jetbrains-tests on this branch); fixing it is out of scope for the FFmpeg bump here. Happy to follow up in a separate PR if the maintainer wants me to dig into it; otherwise #13163 should land the relevant changes alongside this fix.

[santhiprakash]

I have read the CLA Document and I hereby sign the CLA

[santhiprakash]

CI status update — FFmpeg fix works; testAutocomplete failure exposed

Re-verified against the latest push (2e6fadcbd):

• FFmpeg step: Setup FFmpeg succeeds. Cache hit FFmpeg-8.1-373784774-Linux-X64 from the parameterized input, ffmpeg/ffprobe available. The original 7.1/404/tar issue is resolved.
• jetbrains-tests: still failing, but the cause has moved. :testIntegration > Autocomplete.testAutocomplete() now runs to completion (1m04s) and asserts text.contains("TEST_LLM_RESPONSE_0") — fails with expected: <true> but was: <false> at Autocomplete.kt:42. The test never invoked FFmpeg.

This is the same failure mode on every PR that gets past the FFmpeg step. Quick check from recent runs:

PR	FFmpeg step	:testIntegration
#13169 (this)	✓ 8.1 cache hit	✗ Autocomplete.kt:42 assertFalse
#13170	✗ 7.1 404 (untouched action.yml)	skipped — never reached
#13171 (docs-typos)	✗ 7.1 404 (untouched action.yml)	skipped — never reached
ScrewTSW #13165 (closed Aug 19)	n/a (closed before CI ran)	n/a

So once the FFmpeg issue is out of the way, this test has been failing on every PR for at least 2 days. The plugin, the test LLM provider (TestLLM in core/llm/llms/Test.ts, returns TEST_LLM_RESPONSE_<n> for prompts containing TEST_USER_MESSAGE_<n>), and the test config (test-continue/config.json with provider: "test") all look wired correctly. Happy to dig further, but I didn't want to keep the PR blocked on a finding the FFmpeg fix unmasks without surfacing it.

CI failure artifact for the current push: https://github.com/continuedev/continue/actions/runs/32468648181 — jb-failure-report (test report HTML + recording).

cc @ScrewTSW since #13165 was closed on the same CI symptom.