ci: make the deploy job re-runnable after a partial failure

[bdraco]

What do these changes do?

Make the deploy job in ci-cd.yml re-runnable after a partial
release failure.

• The Make Release step is now gated on a preceding gh release view check, so it is skipped when the GitHub Release for the tag
  already exists (instead of failing with HTTP 422 already_exists).
• The PyPI publish step is invoked with skip-existing: true so a
  retry does not fail on dists that were already uploaded.

The existence check matches only the literal release not found
reply for the not-exists branch and re-raises anything else, so auth,
rate-limit, or transient network failures fail loudly with the real
error instead of being mistaken for "release does not exist" and
falling through to Make Release.

Ported from the equivalent yarl change in aio-libs/yarl#1721.

Are there changes in behavior for the user?

No. This only affects how the release pipeline recovers from partial
failures; the produced artifacts and release are unchanged.

Is it a substantial burden for the maintainers to support this?

No; it removes a manual recovery step.

Related issue number

No tracking issue; ported from aio-libs/yarl#1721.

Checklist

• I think the code is well written
• Unit tests for the changes exist - N/A (CI workflow change, exercised by the next release run)
• Documentation reflects the changes - N/A
• If you provide code modification, please add yourself to CONTRIBUTORS.txt - already listed
• Add a new news fragment into the CHANGES/ folder

Agent run details (optional, for reviewers)

Drafted with Claude Code (claude-opus-4-7); reviewed by @bdraco.

Local checks:

• make doc-spelling passes for the new fragment (the 5 remaining
  warnings are pre-existing on master in CHANGES.rst and not
  introduced here); dists was added to
  docs/spelling_wordlist.txt to clear the only new warning from
  the fragment.
• pre-commit run (yamllint, Validate GitHub Workflows, Check
  GitHub Workflows set timeout-minutes, changelog :user: role
  check) all pass for the changed files.

No unit-test suite was run; the change is workflow-only and is
exercised by the next deploy job run.

[codspeed-hq]

Merging this PR will not alter performance

✅ 242 untouched benchmarks

---

_{Comparing bdraco:ci/deploy-rerunnable (1dbd797) with master (6696a1c)}

[webknjaz]

This is why I prefer having workflow_dispatch as a trigger and pushing the tag post PyPI upload.

[webknjaz]

Make this conditional, check the rerun counter GHA puts in the context automatically. The first run shouldn't have this, only restarts.