fix(ci): fail the release run when npm publish fails

[ifaouibadi]

A failed npm publish produced a green release run whose summary read "No new versions to publish." The publish step's exit status was masked and a hard failure was indistinguishable from a no-op.

What changed

release.yml — exit status is no longer masked. pnpm changeset publish 2>&1 | tee … ran under the Actions default shell (bash -e {0}), which does not set pipefail, so the pipeline reported tee's status of 0 and -e never fired. The step now declares shell: bash and set -euo pipefail, and branches on the pipeline's own status.

release.yml — failure and no-op are now distinct. The published boolean became a tri-state result output:

result	Meaning	Step exit
published	New tags were published	0
none	Nothing to release	0
failed	changeset publish exited non-zero	1

All downstream gates read result == 'published'; No release needed reads result == 'none'; a new Publish failed step reports the failure in the job summary instead of the misleading no-op text.

Correct commit identity. The workflow-authored back-merge in release.yml, and the release-branch commit in release-branch.yml, both hard-coded github-actions[bot]. Both now use the repository's standard commit identity. release-branch.yml carried the identical defect and is fixed in the same pass so the next release does not reintroduce it.

Dead code removed. has_changesets was computed and consumed by nothing; it read as a gate that existed. The tri-state result now covers the no-op case properly.

Verification

Both files parse, and actionlint reports no errors (only pre-existing SC2129 style notes on untouched steps). The old and new scripts were run against a stub that mimics the failing publish:

=== OLD (bash -e, Actions default shell) ===
🦋 Exited with code 1
published=false
step exit: 0          <- the defect: green run, "No new versions to publish."

=== NEW (shell: bash + set -euo pipefail) ===
🦋 Exited with code 1
result=failed
step exit: 1          <- job goes red

The other two paths were confirmed the same way: publish output with no New tag: lines yields result=none and exit 0; output containing New tag: yields result=published and exit 0.

Deliberately not changed

workflow_dispatch: was considered and declined. It would let a production publish be started from a button against a chosen ref, widening who can trigger a release. Re-running the failed jobs of an existing run (gh run rerun --failed) already re-triggers a release against the same commit without pushing the release branch, which solves the same problem without widening the trigger surface.

[github-actions]

Thanks for the pull request — it is in the queue and a maintainer will review it.

This repository is maintained on a weekly cadence. Anything opened from outside gets
a human reply within 2 business days; this comment is automation confirming your
pull request landed, and it is not that reply.

What happens next:

• CI runs on the pull request. Check, Build and Test need to be green before
  review — you can push fixes straight to the same branch.
• A maintainer reviews it against CONTRIBUTING.md.
• A change to a package's public API, or a new dependency, needs a maintainer
  decision before it can merge. That is where the call gets made rather than a
  delay, and we will tell you either way instead of leaving it open.

If this is a security fix for an unreported vulnerability, please close it and use
the private channel first — SECURITY.md.
A public pull request describes the flaw to everyone before the fix is released.