ci: add pre-release workflow for per-PR dev builds

[cloudsmith-iduffy]

Description

Add a GitHub Actions workflow that builds and publishes pre-release packages to Cloudsmith for manual testing on a per-PR basis.

Triggered by either:

• Adding the 'pre-release' label to a PR
• Commenting '/pre-release' on a PR

Type of Change

• Bug fix
• New feature
• Breaking change
• Documentation update
• Refactoring
• Other - Developer Experience.

Additional Notes

The idea here is to allow us to generate releases to test out the functionality in various different environments.

[Copilot]

Pull request overview

Adds a GitHub Actions workflow to produce per-PR pre-release (dev) builds of the CLI and publish them to Cloudsmith for manual testing, triggered via a pre-release label or /pre-release PR comment.

Changes:

• Introduces a new Pre-release GitHub Actions workflow triggered by PR label or slash-command comment.
• Checks out the PR head SHA, sets a .dev{pr}{epoch} version, builds sdist/wheel, and publishes them to Cloudsmith.
• Posts install instructions back to the PR and removes the pre-release label after label-triggered runs.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[paddycarey]

Is there much benefit to this over just installing directly from the git branch with pip?

e.g. pip install git+https://github.com/cloudsmith-io/cloudsmith-cli.git@iduffy/pre-release-cli

The new workflow here only builds an sdist and a wheel, so there's no testing the zipapp flow (which is the tricky one), and there's some inherent risk with making actions like this available in a public repo (even if we try to be safe).

If we're going to do a pre-release flow in the repo I think I'd rather see "real" pre-releases pushed to PyPI on merge to main, and then we can choose to manually cut a release when we're happy later.

[cloudsmith-iduffy]

Sounds good paddy!