llvm-project archive checksum is unstable: GitHub serves two different tarballs for the same commit, and `extension.bzl` / `MODULE.bazel.lock` disagree

## Summary

Every build currently fails while fetching `llvm-project`, on Linux and macOS alike. There are two compounding problems:

1. `dependency_support/llvm/extension.bzl` and `MODULE.bazel.lock` record **different** sha256 values for the same archive.
2. GitHub is serving **two different gzip encodings** of that archive depending on which CDN edge you hit, so neither value is reliable.

## Evidence that two variants are being served

The checksum error is *reversed* between your CI and my machine — the same URL, the same day.

`Nightly MacOS` run [35068037046](https://github.com/google/xls/actions/runs/35068037046) (2026-09-16), on a GitHub-hosted runner:

```
Checksum was 539f119d53fa384a8015cf4e36dec177f1ed5ec050e64d6212936015997e2718
but wanted c7f42402d5ecebbacb68734c56761a581d340457c02cc2fb8f1b4835827bebf4
```

My machine, same day:

```
Checksum was c7f42402d5ecebbacb68734c56761a581d340457c02cc2fb8f1b4835827bebf4
but wanted 539f119d53fa384a8015cf4e36dec177f1ed5ec050e64d6212936015997e2718
```

Bazel reports these as "was <actual> but wanted <expected>", so the runner **received** `539f119d…` while I **received** `c7f42402…`.

I verified the download is not truncated or corrupted on my side: `curl` returns HTTP 200 and a complete 280,331,769-byte gzip, hashing to `c7f42402…` on two independent downloads, byte-identical, with a stable ETag across probes. The archive content is genuine — it unpacks to `llvm-project-7024b9e1…/` including `utils/bazel`, and the commit resolves upstream to "[CIR] Support fp strict for vector logical and, or ops" (2026-09-08).

So this is not corruption at either end. GitHub's auto-generated `/archive/.tar.gz` is not byte-stable, which is a known recurring problem with those endpoints.

## The two records disagree

- `dependency_support/llvm/extension.bzl:21` → `539f119d…`
- `MODULE.bazel.lock:986` → `c7f42402…`

That inconsistency is a bug on its own: whichever variant you receive, one of the two records is wrong. It also has a confusing side effect — a stale `extension.bzl` makes Bazel re-evaluate the module extension and write its value back into the lockfile, so a failed build appears to dirty `MODULE.bazel.lock`.

## Impact

- All platforms fail to build from a clean checkout.
- `Nightly MacOS` has **200 consecutive failures with zero successes**, going back to 2026-03-01 (the limit of a 200-run query). Today's failure is this checksum error.

## Why simply bumping the constant is not enough

Changing `extension.bzl` to `c7f42402…` makes it agree with the lockfile and builds fine on my machine — but that is the variant your CI runners are *not* receiving, so it would likely keep CI red. Any single pinned sha256 is only as stable as GitHub's archive generation.

Worth considering something content-stable instead:

- `git_repository` pinned to the commit (deterministic by commit SHA, no tarball hashing)
- a mirrored/vendored copy of the tarball you control
- the `llvm-project` module from the BCR, if it is far enough along for your needs

I am happy to send a PR for whichever direction you prefer, but did not want to guess.

## Related

#1434 (tracking issue: OS X aarch64 build/test status). This is currently the
first failure a macOS build hits, though the problem is not macOS-specific --
it breaks Linux builds from a clean checkout too.

Also #1363 (macosx nightly builds are failing), which reports the symptom; this issue is one of the concrete causes.

## Environment

- macOS 26.6.2, arm64 (Apple Silicon)
- Bazel 8.7.0 (per `.bazelversion`), via bazelisk
- XLS at `fc572666a`