ci(publish): make the PyPI upload idempotent so a Release cannot go red over a duplicate (#57)

`uv publish` fails the run when a file is already on the index, so any version that reached PyPI by another route — a manual `uv publish`, a re-run of this workflow, a partial upload — makes the GitHub Release that triggers it go red even though the package is fine and nothing needs doing.

That is exactly what happened with 1.5.0: it was published by hand before the Release existed, which left cutting the Release as a choice between skipping it (losing the tag and notes every prior version has) and accepting a failed run attached to it.

`--check-url` has uv query the index first and skip files already present, so the step is a no-op instead of an error. Re-running the workflow is now always safe.

Co-authored-by: V. David Zvenyach <dave@zvenyach.com>
Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>

Author: 3 people

.github/workflows/publish.yml

@@ -26,4 +26,8 @@ jobs:
     - name: Publish to PyPI
       env:
         UV_PUBLISH_TOKEN: ${{ secrets.TANGO_PYPI_TOKEN }}
-      run: uv publish
+      # --check-url makes the upload idempotent: uv queries the index first and skips
+      # files already present instead of failing the run. Without it, any version that
+      # reached PyPI by another route — a manual `uv publish`, a re-run of this
+      # workflow — makes the GitHub Release that follows it go red for no real reason.
+      run: uv publish --check-url https://pypi.org/simple/