Add one-click release workflow for cuda-pathfinder

[cpcloud]

Replaces the manual release checklist for cuda-pathfinder with a single
workflow_dispatch that takes a version number.

Pipeline

prepare → docs → publish-testpypi → verify-testpypi → publish-pypi → verify-pypi → finalize

upload-assets runs in parallel with the publish chain (attached to the draft
release with --clobber).

The verify jobs install the package in a fresh venv and assert __version__
matches -- replacing the manual pip install + import step. If TestPyPI
verification fails, PyPI publish never runs.

Notable choices

• Refuses to run from non-default branches (prevents accidental tags from feature branches)
• Fails on duplicate PyPI uploads rather than silently skipping (unexpected state should be investigated)
• Uses existing ci/tools/lookup-run-id and ci/tools/download-wheels unmodified
• All workflow_dispatch inputs flow through env: to prevent shell injection

[copy-pr-bot]

Auto-sync is disabled for ready for review pull requests in this repository. Workflows must be run manually.

Contributors can view more details about this message here.

[mdboom]

I'm generally in favor of this kind of automation and anything that makes it harder to make mistakes in a multi-step process.

I think this suffers from the same race condition problem as #1610. Alice visits GitHub website to make a release ... Bob merges a PR ... The release now has Bob's PR, which wasn't intended. Requiring the user to provide a git hash from which to make the release would help a lot here. Since (if I'm reading this correctly) this workflow doesn't actually push new commits to main (only tags), it should be ok if Bob continues to work while this workflow is running and not cause this workflow to fail.

[cpcloud]

Good point. I'll add that as a required input for now. I wonder if there's a way to make this work. We can of course alter our dev workflow, which might be the only way to reasonably achieve full automation here.

[cpcloud]

@mdboom Thanks for the callout - this concern was valid.

I updated the release workflow to require an explicit commit input and pin the release tag to that exact SHA. The workflow now validates that the SHA is a full commit hash, exists, and is reachable from the default branch. It also fails if the target tag already exists at a different commit.

So merges to main while the workflow is running no longer change what commit is being released.