Publish to PyPI with a trusted publisher instead of an API token

[huangziwei]

Step 3 of the trusted-publishing switch — the half that lives in the repo. The
PyPI side is yours.

Do not merge before configuring PyPI

The workflow is inert until a release is published, and at that point it needs a
matching publisher to already exist. If a release goes out first, it builds and
then fails to upload. At
https://pypi.org/manage/project/rfest/settings/publishing/, add a GitHub
publisher with:

field	value
Owner	berenslab
Repository name	RFEst
Workflow name	python-publish.yml
Environment name	pypi

"Workflow name" is the filename, not the name: inside the file. Nothing needs
doing on the GitHub side: referencing an environment in a workflow creates it.
Repository settings only come into it if you want protection rules on that
environment, such as requiring a reviewer before a publish can proceed.

The change

user: __token__ / password: ${{ secrets.PYPI_API_TOKEN }} are gone. The job
mints a short-lived OIDC token instead, which PyPI exchanges for upload rights
to this project alone. Nothing is stored, so there is nothing to leak or
rotate, and a compromised repo secret stops being a way to publish rfest.

Building and publishing are now two jobs, matching the GitHub starter
workflow. release-build checks out and builds, and uploads dist/ as an
artifact; pypi-publish downloads that artifact and uploads it. The point of
the split is that the job holding id-token: write — the one that can publish —
checks nothing out and runs none of this repository's code. It needs no
contents permission at all.

The action moves from v1.4.2 to v1.14.2. The SHA pinned in the tree is
v1.4.2, which predates trusted publishing by about four years, so adding
id-token: write to it would have achieved nothing. The new pin dc37677… is
the commit behind the v1.14.2 annotated tag; the tag object's own SHA does
not resolve in uses:. actions/setup-python also goes v3 → v5.

A dependabot config comes with it. Pinning to a SHA is the safer way to
depend on a third-party action, but it only works if something bumps it, and
nothing here did — that is exactly how the publish action ended up four years
behind the authentication method it needed. Monthly, github-actions ecosystem,
which also covers checkout, setup-python, setup-uv and the artifact
actions across both workflows.

The starter workflow uses @release/v1, a moving branch, and would sidestep the
staleness problem differently. Pinning is kept because that is what the file
already did and because this job can publish; dependabot is the part that was
missing.

A side effect worth having: from v1.11 the action publishes PEP 740 digital
attestations by default under trusted publishing, so releases become verifiably
built by this workflow.

After the first successful release

Revoke the old credential in both places — the PYPI_API_TOKEN secret in repo
settings, and the token itself at https://pypi.org/manage/account/token/.
Deleting the secret alone leaves a working token in existence.

Testing

There is no dry run for trusted publishing, and PyPI will not accept a
re-upload of an existing version, so the first real proof is the 2.2.0 release
in #40. If you would rather rehearse, add a second publisher on TestPyPI and
point a throwaway workflow at repository-url: https://test.pypi.org/legacy/.

The Tests workflow runs on this PR and should be green; it says nothing about
these files, which only trigger on release.