ci: add publish-on-release workflow for release-please recovery

[lukeocodes]

Summary

Adds a publish-on-release.yml workflow that fires on the release: published event, so a human manually creating a GitHub release (with gh release create v0.X.Y) can drive the PyPI publish through CI without workflow_dispatch and without resorting to local twine upload.

Why

Release-please got stuck on PR #50 with autorelease: pending after the merge. Every subsequent release.yml run aborts at the release-please step (untagged, merged release PRs outstanding), so the existing publish path can't fire. PyPI is on 0.2.19, manifest+pyproject on main say 0.2.20.

Manual recovery options today are:

1. Run gh release create v0.2.20 ... to create the release. But the existing publish job in release.yml is gated on release-please's outputs, not on release events. Manual release alone doesn't trigger publish.
2. Local twine upload against PyPI. Bypasses CI entirely. No.
3. workflow_dispatch to bypass the release-please gate. But workflow_dispatch is what got us into the cli.deepgram.com vs PyPI skew the other day. Removed in ci: remove workflow_dispatch from web-production #54.

This PR adds a fourth option, gated on real release artifacts.

How it works

publish-on-release.yml triggers on release: published. When fired:

1. checks out the released tag
2. installs python + build tools
3. runs make build and make verify-packages
4. uploads to PyPI via the same pypa/gh-action-pypi-publish action and PYPI_API_TOKEN secret as the existing publish job

It only fires for root tags (startsWith(github.event.release.tag_name, 'v')) so sub-package tags like deepctl-cmd-listen-v0.0.10 continue to flow through release.yml.

No double-publish

GITHUB_TOKEN-created releases (which is how release-please's create-release step works) do not trigger downstream workflows. GitHub Actions intentionally blocks that loop. So when release-please's normal flow works, release.yml's existing publish job handles it as before, and this workflow stays asleep. This workflow only fires for human-created releases.

(Same dynamic that the existing web-production.yml comment notes for the workflow_call vs release-published trigger choice.)

Recovery procedure for v0.2.20

After this lands:

1. gh release create v0.2.20 --target 2fab886 --title v0.2.20 --notes "$(curl -s 'https://raw.githubusercontent.com/deepgram/cli/2fab886/CHANGELOG.md' | sed -n '/^## \[0.2.20/,/^## /{/^## \[0.2.20/!{/^## /d}};p')"
2. that fires this workflow → builds + uploads to PyPI
3. relabel #50: autorelease: pending → autorelease: tagged
4. release-please unsticks for future runs

What this PR doesn't do

• doesn't fix release-please's stuck state (manual relabel needed once tag exists)
• doesn't trigger any release itself (no workflow_dispatch, no scheduled run)
• doesn't touch release.yml (the normal flow continues unchanged)
• doesn't extend bump-brew-formula to fire on manual recovery releases (separate concern; brew bump is currently broken anyway due to the deepgram-robot 403 issue)

Verification

• python -c "import yaml; yaml.safe_load(open('.github/workflows/publish-on-release.yml'))" parses cleanly
• only one job, gated on root v* tag
• uses the same SHA-pinned actions as the existing release.yml publish job (actions/checkout@34e1148..., actions/setup-python@a309ff8..., pypa/gh-action-pypi-publish@ed0c539...)