Publish a downloadable build cache (Physlib + PhyslibAlpha)

[Alex-Zughaid]

Summary

New contributors currently compile all of Physlib (554 files), QuantumInfo
(84), and PhyslibAlpha (47) from source on their first build - the same
problem lake exe cache get already solves for Mathlib, but nothing did for
Physlib's own code.

• CI publishes build artifacts on every push to master, via Lake's own
  built-in content-addressed cache (lake cache), backed by a Cloudflare R2
  bucket (physlib-cache, lake-cache.toml).
• scripts/get-cache.sh is a one-command wrapper: it fetches Mathlib's cache
  (via Mathlib's own tool) and Physlib's (via lake cache get against the R2
  bucket), so a contributor runs one command instead of two before their
  first lake build.
• lakefile.toml gains enableArtifactCache / restoreAllArtifacts, which
  is what makes both the CI publish and the local restore work, and also
  means a contributor's own local build populates their own cache, so
  switching branches locally reuses work instead of recompiling.

Measured end to end on a fresh clone: clone + fetch + build in ~4-5 minutes,
compiling zero modules, versus 35+ minutes for a from-source CI build (and
well over an hour locally). Details and the exact numbers are in
docs/cache-setup.md.

Draft - one thing maintainers should weigh in on

The R2 bucket (physlib-cache) is currently on my personal Cloudflare
account. That's fine for developing and testing this, but if this gets
merged, the project would depend on infrastructure owned and billed to me
personally. Before this is mergeable I think that's worth a deliberate
decision - moving the bucket to a project-owned account, or another
arrangement - rather than something noticed after the fact. Flagging it here
rather than waiting for it to be spotted in review.

Everything else has been tested end-to-end against the live bucket,
including CI runs that published real artifacts and a fresh clone that
consumed them successfully on a different OS than CI builds on (Linux CI
artifacts, macOS consumer).

Why R2

For a build cache the cost that scales is egress (every contributor
download), not storage. R2 has zero egress fees at any volume; Mathlib's own
cache uses Azure, which does not. Current bucket usage is ~29MB (well under
the 10GB free tier) for the full Physlib + QuantumInfo + PhyslibAlpha
artifact set, deduplicated by content hash across every push so far.

Test plan

• Local: full round-trip (build, restore, verify lake build is a
  no-op) proven via Lake's own cache mechanics
• CI: stage -> put-staged against the live R2 bucket, verified publicly
  fetchable (correct LTAR content, HTTP 200) from outside CI
• Fresh-clone timing: cold clone -> get-cache.sh -> lake build, 0 modules
  compiled, ~4-5 minutes total
• Cross-platform: CI (Linux) -> local (macOS) cache consumption verified
• Bucket ownership decision (see draft note above)
• Maintainer review of the CI workflow changes

Generated with Claude Code

[github-actions]

Thank you for this pull-request (PR). If this is your first PR, welcome to the community!

Below is what will happen next. Please read carefully if you are not familiar with the process. You may open other PRs while this one is being reviewed, and can stack PRs on top of each other, so don't let these steps slow you down.

1. Some automated checks will be run on your PR. You can see the results of these checks at the buttom of your PR page. If any of these checks fail, you will need to fix the issues before your PR can be merged. You can learn more about these here, including how to run them locally, which is sometimes quicker than relying on the GitHub Actions. If you have never had a PR merged before, you may have to wait for a reviewer to manually start these checks (this is for security).

2. A reviewer will look at your PR and may ask you to make changes. This may happen a couple of days after you submit your PR, so you may need to be patient. But it should not be longer than that - if it is please bring it to the attention of the community on the Zulip. The level of review will depend on where your PR is submitted. If it is submitted to ./Physlib or ./QuantumInfo, the review will be more thorough than if it is submitted to ./PhyslibAlpha. You can find out more about what the review process is looking for in our review guidelines. If a reviewer adds an awaiting-author label to your PR, address the review comments, then please remove that label by adding a comment with -awaiting-author. This helps us keep track of reviews.

3. The reviewer will either approve your PR, or request more changes (in which case we return to step 2). Once your PR is approved, it will be merged by a maintainer, this should happen shortly after approval, though you may get more comments at this stage.

Tip: The easiest way to get have a fast review is to submit a PR that is small and self-contained, and has clear documentation explaining why things are the way they are in your chages.

If you have any problems or questions, please reach out to the community on the Zulip.