Enable PyPI publish workflow on version tag push

[Copilot]

This change adds a direct release path for publishing to PyPI when a new version tag is generated and pushed. Previously, publishing only ran on GitHub Release publication.

• What changed

  • Updated the PyPI workflow trigger in .github/workflows/build.yml from release.published to tag-based push events.
  • Added support for both common tag formats used during version bumps:
    • vX.Y.Z
    • X.Y.Z

• Why this matters

  • Publishing can now start immediately from the version-tagging flow, without requiring a separate Release publication step.

• Workflow trigger example

  on:
    push:
      tags:
        - "v[0-9]*.[0-9]*.[0-9]*"
        - "[0-9]*.[0-9]*.[0-9]*"

---

🔒 GitHub Advanced Security automatically protects Copilot coding agent pull requests. You can protect all pull requests by enabling Advanced Security for your repositories. Learn more about Advanced Security.

[Copilot]

Pull request overview

Updates the PyPI publish workflow trigger so publishing can run directly from version tag pushes (instead of requiring a GitHub Release), aligning release automation with a tag-based versioning flow.

Changes:

• Switched .github/workflows/build.yml trigger from release.published to push on version-like tags.
• Added support for both vX.Y.Z and X.Y.Z tag formats.

[Copilot]

The tag globs here are more permissive than the stated intent of only matching vX.Y.Z / X.Y.Z. In GitHub Actions globbing, [0-9]* means “a digit followed by anything”, so tags like v1.2.3-rc1, v1.2.3.4, or v1.2.3foo can still match and trigger a publish. Consider adding an early validation step (e.g., shell regex check against ^v?\d+\.\d+\.\d+$) to fail fast, or otherwise tightening the trigger so pre-release/suffixed tags don’t publish unintentionally.

[Copilot]

Switching this workflow to run on push tag events means the job (which uses secrets.PYPI_API_TOKEN) will execute based on whatever workflow definition exists in the tagged commit. If someone with tag-push rights can create/move a matching tag, they could potentially run a modified workflow that exfiltrates the token. Consider adding a protected GitHub Environment for publishing (with required reviewers) and pulling the PyPI token from environment secrets, or otherwise gating the publish step to reduce the blast radius of tag-triggered runs.