Handle runner availability gaps when newer patch is not yet on all runners #27
Description
Summary
When a new CPython patch (for example 3.13.9) appears on python.org before it is rolled out to GitHub-hosted runners, the action currently stops with a runner availability failure and never falls back to earlier patches that are supported (e.g., 3.13.8). We should attempt earlier patch versions on the same track before exiting, so repositories can still upgrade past their current patch even while the newest release is unavailable on some runners.
Current behavior
- Latest CPython bundle (3.13.9) is published upstream.
- Runner availability gate blocks because linux/mac/win runners have not yet shipped 3.13.9.
- Action exits with
Runner availability check failed for version 3.13.9. Missing: linux, mac, win, leaving repos stuck on older patches (e.g., 3.13.7).
Desired behavior
- Continue checking earlier patch versions on the same track (3.13.8, 3.13.7, …) until we find the newest version that satisfies runner availability.
- Still surface a warning or note that the latest patch was skipped due to missing runners, but proceed with the fallback upgrade if one exists.
Proposed changes
- Fetch the full patch list for the selected track.
- Iterate from newest to oldest, stopping at the first version that passes the runner availability gate.
- Improve the runner availability failure message to clarify that the newest patch is still rolling out (so users know it is an upstream timing issue, not a bug).
Additional context
This will avoid gaps where automation stalls for days while runner images catch up, and the updated messaging will reduce confusion for maintainers reviewing failed runs.