fix(ci): make npm publish idempotent per version

[harijoe]

Summary

• Guard each pnpm publish behind scripts/publish-if-new.sh, which checks npm view <name>@<version> and skips instead of failing when that exact version already exists.
• Add a concurrency group keyed on the event name and github.sha to the publish job, so two runs that would publish the same version serialize instead of racing.

Context

publish.yml runs on every branch push and derives the version from the commit SHA (0.0.0-dev.<sha7> / 0.0.0-next.<sha7>). Any second publish attempt for a commit already published gets npm's E403 "cannot publish over previously published versions", so the run goes red even though the package is on npm.

Concurrency alone only covers the simultaneous case. The same failure happens for non-concurrent attempts: a re-run of a failed job, or a second branch pushed at the same commit. The idempotence guard is what actually fixes those; the concurrency group closes the remaining window where two runs both read the version as unpublished before either writes.

The key includes github.event_name because a release run and a push run at the same commit publish different versions (latest vs next.<sha> / dev.<sha>), so they must not share a group: a group holds only one pending run, and a queued release run would be displaced by a later push.

The group uses cancel-in-progress: false so the second run queues rather than killing the first. Cancelling could interrupt a release mid-flight and drop the release-only steps (Mintlify deploy, bump PR, Discord notify), and queuing is harmless now that a duplicate run skips instead of 403ing.

The guard is per package rather than per job, so a run that published skybridge but died before @skybridge/devtools can be re-run and will publish only what is missing.

Verification

The branch's own Publish run covers both paths:

• Fresh SHA: published skybridge@0.0.0-dev.643ca28 and the other two packages normally.
• Re-run of that same run: green, with skybridge@... is already published, skipping for all three packages. That re-run is exactly the case that used to fail with E403.

Notes

On a release event, re-publishing an existing tag now logs "already published, skipping" and passes green rather than failing. That is the intended behaviour for job re-runs, but it means a mistakenly re-cut release is no longer loud.

It also means a release re-run reaches the release-only steps instead of dying at the publish step. That is the point (you re-run because the Mintlify push or the bump PR failed), and those two are idempotent: the deploy force-pushes the same commit, and the bump PR updates the fixed chore/bump-versions branch. The Discord notification does fire a second time.

[greptile-apps]

Greptile Summary

The PR makes npm publication idempotent and serializes runs targeting the same event and commit.

• Adds a package-level guard that skips versions already present in npm.
• Routes all three package publications through the guard.
• Adds event-and-SHA-scoped workflow concurrency without cancelling active runs.

Confidence Score: 5/5

The PR appears safe to merge.

No blocking failure remains.

_{Reviews (6): Last reviewed commit: "fix(ci): scope publish concurrency group..." | Re-trigger Greptile}

[harijoe]

@greptileai review