ci(windows): take the package feed off the Windows legs entirely (#824)

[fujibee]

Declared reviewers: 1

Closes #824.

CI only. No change to anything shipped — the diff is one file, .github/workflows/tests.yml, and it touches only the Windows bats legs' setup steps. Nothing a user installs or runs is different.

#827 made a chocolatey outage legible. This removes the cause.

Why now, when #827 just landed

The issue's own Directions ranked the retry last — "the cheapest change and the least durable" — and that was right: on a cache miss the leg still needed community.chocolatey.org.

What changed is the weight. bats is a required check on main with enforce_admins: true, so a red Windows leg blocks every landing in the repository and nobody can wave it through. "The leg is red but it's just the feed" stopped being an annoyance and became a stop.

The replacement, measured rather than looked up

https://sqlite.org/2026/sqlite-tools-win-x64-3530400.zip
  status 200, 6,557,792 bytes
  sha256 f46ee2475de4cbe287e6e5f7d43c838796b14e7379cd216bdbb28d391429f9fc
  archive listing contains sqlite3.exe (4,022,272 bytes)

All four come from fetching it: the URL answered, the digest is of those bytes, and the archive was listed to confirm the binary is inside. The four pins in env: reconcile against that one artifact — YEAR+BUILD build the URL, SHA256 is its digest, VERSION keys the cache.

What is gone is the feed, not the third party. sqlite.org is still somebody else's host. What it is not is a package index: no resolver, no two-phase lookup, and nothing that answers 503 for one concurrent job while serving another — which is precisely the behaviour that made the original failure unreadable. On 2026-08-15 the same outage reddened Install sqlite3 on one branch and Run tests on another, depending on which phase chocolatey happened to fail in.

The hash is load-bearing. Without it this trades a feed that answers errors for a host that could answer anything, and the tests would run against whatever arrived. A mismatch fails the download step by name.

Kept from #827

The presence check, deliberately. Whatever supplies sqlite3, the step that decides the leg's colour must be the one that says the dependency is missing — not the one that runs the tests. That is the part of #827 that survives a change of supplier, and it is why this PR is small.

The retry survives too, at one attempt-triple: a single host can still have a bad second. It is no longer a package index having a bad phase.

Also corrected

A comment #827 left behind said a version bump means "one trip to chocolatey, which is the only time the community feed is asked at all". There is no feed to ask. The env block now says what the four pins are and that bumping a release means changing all four together — a stale SHA256 fails loudly, which is the intended way to discover one was missed.

Not measured

• Whether the runner already ships sqlite3. Absent from the Windows 2022 and 2025 image manifests — the published software list, not a where sqlite3 on a live runner. If it turned out to be there, this whole block could go.
• The fetch from a runner's network. The URL was measured from a developer machine. The presence check is what reports it if a runner cannot reach it, and it names the download rather than the tests.
• A cache hit. The key changed (sqliteorg rather than choco), so the first run on this branch is a miss by construction.