Install uv through setup-uv v10.3.3 in every workflow - #1892

Purpose of the change

Make every workflow install uv the same way, at the current release.

Description

• Every workflow installs uv through astral-sh/setup-uv@v10.3.3 with no version input, so all of them get the current uv release. The four workflows that ran pip install uv now use setup-uv like the others, the lockfile check moves off v4, the security audit drops its setup-uv v8.1.0 step pinned to uv 0.11.15, and the rest move off v6, whose tag is frozen at v6.8.0 because setup-uv publishes no moving major tags since v8.
• Each setup-uv step sets prune-cache: true, because v9 changed that default to false and without it every job saves its whole uv cache, downloaded torch and CUDA wheels included. The other v7 to v10 behavior changes (node24 runtime, manifest-file format, cache disabled for pull_request_target and workflow_run) touch nothing these workflows use.
• The three package workflows no longer upgrade pip or install the build package: every package is built with uv build, which drives the setuptools backend in its own isolated environment, and nothing invoked python -m build. The pip installs that exercise the built wheels stay.
• The security audit relocks with the current uv. uv 0.11.15 rewrites the lockfile's dependency markers on every real relock, which is the marker churn in its fix PR fix(security): upgrade vulnerable Python dependencies #1433: upgrading mako alone changes 160 lockfile lines under 0.11.15 and 6 under 0.13.6. The comment and step summary of its OSV skip branch named the removed version: input and now refer to the uv release setup-uv installs; the branch itself stays, and its removal is Security Audit workflow blocked by upstream uv audit OSV parse failure (#19492) #1424.
• uv.lock, the Dockerfile and the docs are unchanged.

Why these choices

• An immutable tag, not a commit SHA, for setup-uv. Its releases are published as GitHub immutable releases, so v10.3.3 cannot be moved; the SHA form would add nothing for this action. Every other action here is referenced by a floating major tag and Dependabot does not cover actions in this repo, so a lone SHA would be an orphan nobody updates. Repo-wide SHA pins with a github-actions Dependabot entry are a separate PR.
• A pruned uv cache, not the full cache and not none. Measured from CI logs, from the start of the cache restore to uv's installed environment, as medians: on Linux a pruned hit takes 22 s, a full hit 41 s and a run with nothing cached 33 to 34 s; on macOS 12, 25 and 36 to 38 s; on Windows 16, 29 and 41 to 43 s. Restoring about 3 GB is slower than downloading the same wheels again, while the pruned cache keeps the wheels uv builds from source, here hnswlib, which it otherwise compiles on every run. Saving a pruned cache takes about 1 s on Linux against 15 s for a full one, and the pruned caches are megabytes where the full Linux caches are about 3 GB each, more than the repository's 10 GB of cache storage once a few are saved.
• No uv version requirement. Of the 75 most-starred Python repositories that commit a uv.lock, 64 declare none and the other 11 declare a floor for a uv feature they rely on; none pins an exact release. Nothing here relies on one: the lockfile is read, checked and installed from by 0.11.15, 0.12.0 and 0.12.15, including a lock written by 0.12.23 at its newer revision.
• The pip and build installs go because nothing used them. uv build creates its own isolated environment and drives the setuptools backend directly; the common package's sdist and wheel build with no build package present anywhere.

Fixes/Closes

None. Split from #1807, which keeps the removal of the security audit workflow.

Type of change

• Project Maintenance (updates to build scripts, CI, etc., that do not affect the main project)

How Has This Been Tested?

• Manual verification

• actionlint passes on every workflow, and bash -n passes on the security audit's run: blocks.

• uv 0.13.6 (current): uv lock --check passes on this branch's lockfile, and uv audit --output-format json exits 1 with findings in an output carrying the vulnerabilities[].dependency.name fields the audit parses.

• This branch's workflow files other than security-audit.yml, which Install uv through setup-uv v10.3.3 in every workflow and remove the security audit workflow #1807 deletes, are identical to Install uv through setup-uv v10.3.3 in every workflow and remove the security audit workflow #1807's head 246be87. Every check on that head passed, with setup-uv v10.3.3 installing uv 0.13.6 on Linux, macOS and Windows and pruning the cache before saving it. CI skips draft pull requests, so this PR's own checks run once it is marked ready.

Test Results: as listed above.

Checklist

• I have signed the commit(s) within this pull request
• I have performed a self-review of my own code

Further comments

• This carries the setup-uv half of Install uv through setup-uv v10.3.3 in every workflow and remove the security audit workflow #1807 so it can merge without waiting on the decision to remove the security audit. Once this merges and main is merged into Install uv through setup-uv v10.3.3 in every workflow and remove the security audit workflow #1807, that PR's diff is the deletion of security-audit.yml alone.
• After this merges, merging main into Install uv through setup-uv v10.3.3 in every workflow and remove the security audit workflow #1807 conflicts on security-audit.yml, edited here and deleted there. GitHub's web editor resolves only competing line changes, so that merge is done locally, keeping the deletion.

🤖 Written by Claude Code (Claude Opus 5.5) on behalf of @edwinyyyu.