Update `uses: astral-sh/setup-uv@...` references in documentation to
`11f9893b081a58869d3b5fccaea48c9e9e46f990 # v8.3.2`.

Co-authored-by: eifinger <[email protected]>

chore: update known checksums for 0.11.29

Co-authored-by: eifinger <[email protected]>

#961)

## Summary

`getLinuxOSNameVersion()` throws `Failed to determine Linux
distribution. Could not read /etc/os-release or /usr/lib/os-release` on
distributions whose os-release is readable but contains **no version
field at all** — no `VERSION_ID`, no `VERSION_CODENAME`, no `BUILD_ID`.
The error message is misleading in that case, and the action fails even
though the distribution is perfectly identifiable.

Void Linux is such a distribution. Its os-release is:

```sh
$ cat /etc/os-release
NAME="Void"
ID="void"
PRETTY_NAME="Void Linux"
HOME_URL="https://voidlinux.org/"
DOCUMENTATION_URL="https://docs.voidlinux.org/"
LOGO="void-logo"
ANSI_COLOR="0;38;2;71;128;97"

DISTRIB_ID="void"
```

Unlike Arch (fixed by #912 via `BUILD_ID`) and debian:unstable (fixed
via `VERSION_CODENAME`, #773), Void ships only `ID`, so both existing
fallbacks miss it. This breaks any workflow using `container:
ghcr.io/void-linux/void-glibc-full` with caching enabled — e.g.
SageMath's CI started failing after bumping to v8:
https://github.com/sagemath/sage/actions/runs/29456228986/job/87489892141
(worked around downstream in sagemath/sage#42547
by injecting a fake `BUILD_ID` into the container's os-release).

This PR adds a last-resort fallback: if `ID` is present but no version
field is, return the plain `ID` (`void`), following the same reasoning
as #912 — a stable cache key for a rolling release is better than
crashing. Distributions with a version field are unaffected, and files
without even an `ID` still raise the existing error.

## Summary

- update all CodeQL actions from 4.36.2 to 4.37.0
- update `smol-toml` from 1.6.1 to 1.7.0
- update `@types/node` from 25.5.0 to 26.0.1
- update `@vercel/ncc` from 0.44.0 to 0.44.1
- regenerate bundled action artifacts

Supersedes #950, #951, #952, #957, #958, and #959. The updates from #905
and #907 are already present on `main`.

Refs: pi-session 019f796d-a374-7a76-a8e4-1699b89ec8e6

## Summary

This changes the default for `prune-cache` from `true` to `false`,
motivated by [#745](#745).
Users that want the existing behavior can continue to set `prune-cache:
true` explicitly.

Some history: I originally added [`uv cache prune
--ci`](astral-sh/uv#5391) after looking at a
workload where the uv cache was ~2.2 GB, almost entirely due to the
enormous pre-built `torch` and `nvidia_cudnn_cu12` wheels ([original
analysis](actions/setup-python#822 (comment))).
Persisting and restoring thousands of extracted files through the GitHub
Actions cache could be slower than downloading the wheels again. In
contrast, wheels built from source can be very expensive to recreate.
The intent was to remove pre-built wheels while retaining locally-built
wheels.

`setup-uv` subsequently made pruning configurable, but defaulted
`prune-cache` to `true`; it also later enabled caching by default on
GitHub-hosted runners. As a result, the default configuration repeatedly
downloads pre-built wheels from PyPI even on a cache hit. That tradeoff
has become more important as uv adoption has grown: [the PyPI analysis
in
#745](#745 (comment))
estimates that uv accounts for roughly half of reported CI downloads
from PyPI, and roughly 65-75% for `boto3`.

I ran the comparison across a few different workloads:

| Workload | PR | Packages | Cache: keep / prune / prune-ci | Warm
restore+sync: keep / prune / prune-ci | Downloads: prune / prune-ci |
|---|---:|---:|---:|---:|---:|
| Tiny | [#1](astral-sh/setup-uv-benchmarks#1) |
19 | 6 / 6 / 2 MB | 0.3-0.4 / 0.3 / 0.4-0.5 s | 0 / 2 |
| Web | [#2](astral-sh/setup-uv-benchmarks#2) |
65 | 43 / 43 / 7 MB | 0.6-1.0 / 0.5-0.6 / 1.5-1.7 s | 0 / 6 |
| Scientific |
[#3](astral-sh/setup-uv-benchmarks#3) | 118 |
586 / 586 / 8 MB | 8.2-16.0 / 7.0-8.2 / 8.9-12.1 s | 0 / 19 |
| PySpark |
[#4](astral-sh/setup-uv-benchmarks#4) | 19 |
1820 / 1820 / 436 MB | 9.9-21.1 / 10.5-11.0 / 5.0-7.0 s | 0 / 4 |
| CPU PyTorch |
[#5](astral-sh/setup-uv-benchmarks#5) | 14 | 182
/ 182 / 1 MB | 3.0-6.0 / 3.6-4.0 / 5.7-6.4 s | 0 / 6 |
| CPU-PyTorch ML |
[#6](astral-sh/setup-uv-benchmarks#6) | 137 |
346 / 346 / 10 MB | 7.4-18.0 / 8.8-8.9 / 9.7-11.9 s | 0 / 20 |
| CUDA PyTorch |
[#7](astral-sh/setup-uv-benchmarks#7) | 201 |
2316 / 2315 / 16 MB | 30.2-67.9 / 31.0-63.6 / 33.3-36.7 s | 0 / 40 |

The CUDA workload intentionally reproduces the original `torch==2.1.1`
example. Keeping wheels again produces a ~2.3 GB Actions cache. Across
nine warm runs, restoring that cache ranged from slightly faster than
re-downloading to roughly twice as slow; pruning consistently
re-downloaded 40 distributions in ~33-37 seconds ([original
runs](https://github.com/astral-sh/setup-uv-benchmarks/actions/runs/29750292738),
[additional
runs](https://github.com/astral-sh/setup-uv-benchmarks/actions/runs/29761705492)).

I also tried running `uv cache prune --force` without `--ci` across
every workload, to see if it provided a useful middle ground. It did not
meaningfully reduce any of the caches: plain prune took 11-21 ms and
left the extracted cache and file count unchanged, including PySpark. On
these fresh caches, there are no dangling entries to remove; without
`--ci`, the pre-built wheels and unpacked source/build artifacts are
retained. The per-workload runs are linked in the table above.

So the original motivation still holds for very large CUDA or
source-heavy workloads, but it is not representative of the common case.
For smaller workloads, keeping pre-built wheels is generally faster and
avoids repeated PyPI traffic. This changes the default accordingly,
while retaining `prune-cache: true` as an opt-in for workloads where the
smaller cache is worthwhile.

Closes #745.

chore: update known checksums for 0.11.30

Co-authored-by: eifinger <[email protected]>

## Summary

Roll up the remaining dependency changes from Dependabot PRs:

- #966: update `actions/setup-node` from 6.4.0 to 7.0.0
- #965: update `js-yaml` from 4.1.1 to 5.2.1
- #964: update `@types/node` from 26.0.1 to 26.1.1
- #963: update `esbuild` from 0.28.0 to 0.28.1

PRs #907 and #905 require no net changes because `@renovatebot/pep440`
5.0.0 and Jest 30.4.2 are already on `main`.

## Validation

- `npm run all`

Refs: pi-session 019f854e-4714-73ad-8de2-e79900f41b4d