fix(release): recover atomically from push races

[kayodebristol]

What changed

• Atomically push the release commit and package tag so a rejected main push cannot leave an orphan tag.
• Rebase onto the current protected branch and re-run package validation before each bounded retry.
• Add an explicit recovery_tag input that validates an existing immutable package tag, creates its GitHub Release, and publishes it without a second version bump.

Root cause

The Design Dojo release created and pushed design-dojo-v0.21.1, but a concurrent merge advanced main before the version commit could be pushed. The separate ref pushes left a valid tag without a mainline version commit, GitHub Release, or npm publication.

Recovery

Once the corresponding caller forwards recovery_tag, dispatch it with design-dojo-v0.21.1 to publish the already validated artifact from that immutable tag.

Validation

• actionlint .github/workflows/npm-package-release-reusable.yml
• Git Bash syntax check of the atomic retry loop
• Recovery-tag manifest check: design-dojo-v0.21.1 contains package version 0.21.1

[Copilot]

Pull request overview

This PR hardens the reusable npm package release workflow against concurrent updates to the protected branch by pushing the version commit and package tag atomically with bounded retries, and adds a recovery path to publish an already-created immutable package tag.

Changes:

• Add recovery_tag input to validate an existing package tag’s embedded package.json version and run a release/publish flow without creating a new version.
• Make the release push atomic (git push --atomic) and retry up to 3 times with fetch/rebase + re-validation to recover from protected-branch push races.
• Ensure explicit target_version can still trigger a release even when there are no package-directory commits.

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.