[v3-3-test] Pin providers in constraints to the versions published in PyPI (#71324)

[potiuk]

• Pin providers in constraints to the versions published in PyPI

Constraints cut for a release candidate had to land on the wave being voted on, whose providers exist in PyPI only as rc versions. Asking uv for a pre-release strategy left it free to answer with any version satisfying the lower bounds, so the pins were neither the candidate nor the last release, and what a candidate shipped depended on how the resolution happened to go.

Retrieving the versions from PyPI and naming them leaves nothing to resolve: the constraints pin what is actually published. A pre-release is only ever considered when the run allows it, and even then it has to sort above every final release, so a provider without a candidate in the wave keeps its release and a released constraints file can never carry an rc pin.

A candidate is exempt from the downgrade check - it sorts below the releases the constraints branch already carries, so the comparison says nothing there.

Re-running the workflow for the same candidate now replaces that candidate's branch and tag instead of pushing onto them, so the two always describe the run that produced them and a wave can be re-cut.

• fixup! Pin providers in constraints to the versions published in PyPI

• fixup! Pin providers in constraints to the versions published in PyPI

• fixup! Pin providers in constraints to the versions published in PyPI

• fixup! Pin providers in constraints to the versions published in PyPI

• fixup! Pin providers in constraints to the versions published in PyPI

(cherry picked from commit f9b72d8)

---

Was generative AI tooling used to co-author this PR?

• Yes (please specify the tool below)

---

• Read the Pull Request Guidelines for more information. Note: commit author/co-author name and email in commits become permanently public when merged.
• For fundamental code changes, an Airflow Improvement Proposal (AIP) is needed.
• When adding dependency, check compliance with the ASF 3rd Party License Policy.
• For significant user-facing changes create newsfragment: {pr_number}.significant.rst, in airflow-core/newsfragments. You can add this file in a follow-up commit after the PR is created so you know the PR number.