Regenerate the stdlib map on a weekly schedule

[StefanKarpinski]

This workflow only runs when somebody dispatches it, so the map is correct about a new Julia release only if a person happens to act.

Julia 1.13.1 was released 2026-09-26, bumping LLD_jll and libLLVM_jll to 20.1.8+2 and LibSSH2_jll to 1.11.104+0. The map had last been regenerated 2026-09-08, so it was wrong about 1.13.1 from the moment that version existed — and would have stayed wrong for as long as nobody looked.

It got fixed two days later, but only by accident: a downstream consumer (Resolver.jl, which pins this package to answer "what does Julia X bundle") resolved 1.13.1 against 1.13.0's versions, its CI caught the mismatch, and I dispatched this workflow by hand. That became #60, then 2.0.8.

A Monday cron bounds the staleness at a week and means nobody has to think of it:

on:
  schedule:
    - cron: '0 6 * * 1'
  workflow_dispatch:

The generator is untouched. create-pull-request updates the existing bot/update-historical-stdlibs branch rather than opening a second one, so a week with no new Julia release costs a no-op run and no PR churn.

What this doesn't fix

Worth being explicit, since a schedule can look like more of a solution than it is:

• The bot's PRs still can't start CI. GITHUB_TOKEN-created PRs never trigger workflows — the workflow's own PR body says so — so each still wants a close/reopen to run check_hsg. Solving that properly needs a PAT or pull_request_target, which felt like a separate decision rather than something to bundle in here.
• Releasing is still manual. The version bump and registration aren't automated, so this shortens the gap between a Julia release and a pull request, not between a Julia release and a registered version. For consumers pinning from the registry, that second gap is the one that bites.
• GitHub disables scheduled workflows after 60 days of repository inactivity. This repo is quiet enough for that to matter, so the cron may need a nudge — or the inactivity notice may need acting on — to stay live.

Happy to drop the cron to monthly, or to pair it with an automated version bump, if either fits better with how you'd rather run releases here.

🤖 Generated with Claude Code

https://claude.ai/code/session_011hjZ6pHxaSNseY8pa5SKBx

[StefanKarpinski]

@IanButterworth, what do you think — is this a good idea?

[IanButterworth]

SGTM. Might be worth adding to the release todo list too

[StefanKarpinski]

Would you merge this if it looks good and then make that change? Or do you want me to ask my 🤖 to do it?

[IanButterworth]

I don't know where the release TODO is. @ararslan @KristofferC what do you think about adding regenerating this once a release is out?

1. Trigger https://github.com/JuliaPackaging/HistoricalStdlibVersions.jl/actions/workflows/run_hsg.yml
2. Reopen the PR it makes to trigger CI
3. Merge the PR once done
4. Tag a new release

A lot of that is obvious, just listing so the reality of the task is clear.