Update filelock past GHSA-v4x8-3wr5-3wq8 (needs virtualenv 21.14 first) #480

Problem

Since 2026-10-23 the required security check fails on every branch, main included (run 40155222249 at e02a52e). pip-audit reports three advisories against the locked filelock 3.32.0, all fixed in 4.2.1:

• GHSA-v4x8-3wr5-3wq8 / CVE-2026-112940 (high): ReadWriteLock reopens its SQLite database by name, so a planted symlink or journal file makes the locking process overwrite or unlink its own files.
• GHSA-9vhv-jxww-xfm5 / CVE-2026-112913 (low): on Windows, ReadWriteLock acts on SQLite side files another local user places beside its database.
• GHSA-567q-5qvw-pf92 / CVE-2026-112907 (low): on Windows, an oplock on a soft lock's marker holds SoftFileLock.acquire() past its timeout.

filelock comes in through huggingface-hub (runtime, the [agent] extra, which allows filelock>=3.10.0), and through python-discovery and virtualenv (dev).

Blocker

The locked virtualenv 21.7.13 requires filelock<4, so filelock cannot move to 4.x on its own. virtualenv 21.14.9, which Dependabot proposes in #474, allows filelock<5,>=3.24.2.

Fix

Take virtualenv 21.14.9 from #474. Then the Relock workflow regenerates uv.lock with filelock 4.2.1 or later and runs the full gate on it.

Done when

• main locks filelock 4.2.1 or later, and security passes there.