Require a full test run on the release commit before publishing

[laughingman7743]

Use case

Since #837, a pull request can merge without running the SQLAlchemy compliance suites or the Spark tests, when it does not change their paths. With #850, it would also run only the newest Python version. The weekly schedule catches regressions later, but a release must not ship without every suite having passed on every supported Python version at the released commit.

Today the release procedure relies on a maintainer dispatching test.yaml on master and waiting for success before pushing the tag. release.yaml (tag push) builds and publishes to PyPI without checking anything.

Proposed change

Make release.yaml refuse to publish unless the full test matrix has passed for the tagged commit. Options:

1. Verify an existing run (preferred). Before building, a job queries the GitHub API for a successful Test run with head_sha equal to the tag commit and event workflow_dispatch or schedule. Only these events run every suite on every Python version. The job checks that every expected job (PyAthena, SQLAlchemy, and SQLAlchemy async suites × all supported Python versions, Spark included) succeeded and none was skipped. This keeps the current procedure (dispatch on master, then tag) and adds no AWS cost.
2. Run the tests in the release workflow. release.yaml calls the test suites for every Python version and publishes only if they pass. This is simpler to reason about but runs a second full matrix when the maintainer has already dispatched one. The OIDC role's trust policy (repo:<org>/<repo>:*) already allows tag refs.

Either way, document the gate in the release procedure. A failed or missing run must stop the release before the PyPI upload, because PyPI does not allow re-uploading a version.

Validation plan (if implementing)

• Push a tag on a fork or a test tag with no matching full run: the release stops before build/publish.
• With a successful full dispatch run on the tag commit: the gate passes.
• A run with any skipped or failed suite job does not satisfy the gate.

[laughingman7743]

Note: the 3.x maintenance branch now exists (branched from v3.36.0) for 3.x patch releases while master moves to 4.x. The gate must also work for tags pushed on 3.x: it verifies a full run for the tagged commit, regardless of the branch. 3.x carries the v3.36.0-era Test workflow, which runs every suite on dispatch. The gate itself only needs to exist on 3.x if a 3.x release should also be protected by it, which means backporting release.yaml changes there.