fix: checkout release tag in build job, add manual re-publish trigger

[mldangelo]

Problem

promptfoo 0.1.3 never published to PyPI. Root cause:

The build job used actions/checkout@v6 without a ref, so it checked out GITHUB_SHA — the commit that triggered the push event. When release-please creates a release tag during an earlier push (before the version-bump PR is merged), the build job ends up checking out a commit where pyproject.toml still has the old version. Version mismatch → exit 1 → artifact never uploaded → PyPI publish never ran.

Concretely for 0.1.3: release-please tagged promptfoo-v0.1.3 when PR #28 (README) was merged, but pyproject.toml at that commit said 0.1.2. Build failed. PR #29 (version bump to 0.1.3) merged moments later, but by then release_created was already false for that run.

Fixes

• Checkout the release tag (ref: ${{ steps.resolve.outputs.tag }}) instead of GITHUB_SHA, so pyproject.toml always matches the tagged version
• Derive expected version from the tag (${TAG#promptfoo-v}) rather than release-please output — more robust to timing issues
• Add workflow_dispatch with tag input so a failed release can be re-published without any new commits — just run the workflow manually with tag=promptfoo-v0.1.3
• Run unit tests in the build job before publishing (previously only did an import check)

Immediate action needed

After this merges, manually trigger the workflow to publish 0.1.3:

Actions → release-please → Run workflow → tag: promptfoo-v0.1.3

Test plan

• Merge this PR
• Manually run the release-please workflow with tag=promptfoo-v0.1.3
• Verify promptfoo==0.1.3 appears on PyPI
• Verify future releases build from the correct tag commit