fix(publish): run communique after release is published

[jdx]

Summary

• communique generate --github-release calls GET /releases/tags/{tag} to find the release to update
• That endpoint only returns published releases; draft releases return 404
• While the code has a fallback to GET /releases?per_page=10 (which does include drafts), it ran within ~700ms of the draft being created — before GitHub's list API reflected it
• Moving communique to after gh release edit --draft=false guarantees the release is visible and eliminates the race entirely

Also fixes the related communique bug in ~/src/communique: Err(_) => Ok(None) was silently swallowing list-endpoint errors, making the draft fallback fail invisibly.

Test plan

• Trigger a tag push and verify communique successfully updates the release notes after it's published

🤖 Generated with Claude Code

---

Note

Low Risk
Low risk workflow-only change that reorders when release notes are generated; main risk is altering release automation timing/behavior if the post-publish step fails (it is continue-on-error).

Overview
Moves the communique generate --github-release step out of the draft-release creation job and into the release job after gh release edit --draft=false (and only for non-workflow_dispatch runs).

This ensures release-note enhancement runs against a published release, avoiding race conditions where GitHub’s tag/release lookup APIs can’t find newly created drafts yet.

^{Written by Cursor Bugbot for commit 6a7c6ef. This will update automatically on new commits. Configure here.}

[gemini-code-assist]

Note

Gemini is unable to generate a summary for this pull request due to the file types involved not being currently supported.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 77.88%. Comparing base (d562fb5) to head (6a7c6ef).

Additional details and impacted files

@@           Coverage Diff           @@
##             main     #512   +/-   ##
=======================================
  Coverage   77.88%   77.88%           
=======================================
  Files          48       48           
  Lines        6660     6660           
  Branches     6660     6660           
=======================================
  Hits         5187     5187           
  Misses       1109     1109           
  Partials      364      364           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[jdx]

Superseded by #513, which goes further by extracting communique into its own dedicated job.

[Copilot]

Pull request overview

This PR fixes a race condition in the release publishing workflow where communique was being called before the GitHub release was published, causing the GitHub API call to fail. The fix moves the communique step to after the release is published and adds retry logic for tag indexing delays.

Changes:

• Moved communique release notes enhancement to run after gh release edit --draft=false instead of immediately after draft creation
• Added retry loop (up to 30 attempts) when creating draft releases to handle GitHub's tag indexing delay
• Added validation to ensure created releases have the correct tag name before proceeding

---

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

[Copilot]

The inline comment explaining this awk command was removed. Consider adding a brief comment explaining that this extracts the first version section from CHANGELOG.md, as complex awk one-liners can be difficult to understand at a glance.

Suggested change

	TAG_NAME="${{ github.ref_name }}"
	# Extract the first version section from CHANGELOG.md for the release notes

[Copilot]

The hardcoded values 30 attempts and 5 seconds sleep time (totaling 150 seconds maximum wait) lack explanation. Consider adding a comment explaining the rationale for these specific timeout values, or extracting them as named variables for better maintainability.