Make the release job idempotent on re-run

[Brar]

Follow-up to #16: make the release job recoverable on an Actions re-run.

gh release create has no guard for an already-existing Release, so a re-run after a transient failure would hard-fail. A re-run reuses the original push payload (created stays true), so the retag guard does not protect against it. Guard the create with a gh release view … || gh release create existence check. The dev-snapshot Release attaches no asset, so nothing needs re-doing on the skip path.

[Copilot]

Pull request overview

Makes the tag-triggered GitHub Release publishing step recoverable on GitHub Actions re-runs by avoiding a hard failure when the Release already exists.

Changes:

• Add an existence check (gh release view … || gh release create …) before creating a GitHub Release on tag push.
• Document the re-run behavior rationale inline in the workflow step.

[Brar]

Review — approved

The bare-Release counterpart to the same idempotency fix — gh release view "$tag" >/dev/null 2>&1 || gh release create …. Correct that no re-attach is needed here (neoipcr ships no asset; the tag itself is the deliverable that downstream pinned-sources.yml / compatibility.yml consume), so the plain view-guard is the right, minimal shape — matching NeoIPC-Reporting#23's version and deliberately simpler than neoipc-app#16's re-attach path.

Copilot's review is summary-only (no findings) and accurate. CI green (full R matrix + coverage; the Windows job was still finishing but the change is workflow-only). No open concerns — good to merge. This comment is the sign-off — formal Approve isn't available on one's own PR.

---

Generated by Claude Code