[cap10morgan]

Summary

• Upgrade Leiningen to 2.13.1, pinning the release tag to its commit d109a01c ("Release 2.13.1").
• Keep Leiningen's signing key in the repo. Lein builds fetched the key from keyserver.ubuntu.com and failed whenever that timed out, which happens often when building many images in parallel. Builds now import resources/lein-signing-key.asc and still check it against the keyserver:
  • keyserver copy matches → build continues
  • keyserver unreachable → warning, build continues with the local copy
  • keyserver copy differs (revoked, expiry changed, new subkey or user ID) → build fails, prints both copies and says to run bb refresh-lein-key
• Add bb refresh-lein-key, which fetches the key, checks it's the pinned fingerprint, and writes a minimal export to resources/.
• Shorten smoke test log lines. The lein routing check passed its whole script and Clojure form as arguments, so each image logged ~25 lines; multi-line args now log as a line count and long args are truncated.

Regenerated Dockerfiles aren't included; CI regenerates target/ on master.

Testing

• bb test (28 tests, 0 failures) and bb fmt-check pass.
• Local arm64 builds of the lein variants on Debian, Ubuntu (jammy, noble, resolute), and Alpine, plus latest, with smoke tests via bb build-images.
• Exercised all three key-check paths with real builds: matching key (Debian and Alpine), unreachable keyserver, and a local key with its subkey removed (fails with the expected message).
• bb refresh-lein-key leaves an up-to-date key file byte-for-byte unchanged and restores a modified one.

🤖 Generated with Claude Code

[cap10morgan]

@Quantisan I did a little more than just a version bump in here, so wanted your review. Thanks!

[Quantisan]

Thanks! vendoring the key seems reasonable. I'm not sure if it should be code in the image's Dockerfile. Can we do the key server comparison in our CI here, perhaps?