fix(ci): make release publish step idempotent

[wardbox]

Summary

The Release workflow has been failing on every infra-only merge to main (PR #17, PR #19) with:

```
npm error You cannot publish over the previously published versions: 0.2.7.
```

Why: `changesets/action` runs the `publish` script (`pnpm release`) whenever there are no pending changesets. The previous script ended with a direct `npm publish` — not idempotent — so any merge that didn't include a `.changeset/*.md` file would fail at publish time, even though there was nothing new to ship.

Fix: a small `scripts/publish-if-new.mjs` guard that checks `npm view @wardbox/whisper@` and only runs `npm publish` when the version isn't already on the registry.

• Trusted publishing + provenance flags preserved verbatim
• E404 from `npm view` (= "not published yet") is the happy path
• Any other registry/network error surfaces as exit non-zero

Reference failing run: https://github.com/wardbox/whisper/actions/runs/25018663341

Test plan

• CI passes on this branch (build + smoke matrix)
• After merge, the Release workflow run on main succeeds with the message `publish-if-new: @wardbox/whisper@0.2.7 already on registry — skipping publish.`
• Next time a real changeset is merged, version bumps and publish runs as before

🤖 Generated with Claude Code

Problem

The Release workflow fails on infra-only merges when changesets/action runs the publish script with no pending changesets. Previously, the npm publish command would fail with "You cannot publish over the previously published versions" errors.

Solution

Introduces an idempotent publish guard script (scripts/publish-if-new.mjs) that:

• Reads the package version from packages/whisper/package.json
• Checks the npm registry with npm view @wardbox/whisper@<version>
• Skips publishing if the version already exists (clean success exit)
• Publishes with --access public --provenance flags only if the version is not yet on the registry
• Propagates non-404 registry errors as failures

The scripts.release in package.json now invokes this guard script instead of running npm publish directly.

Files Changed

• package.json: Updated release script to call node scripts/publish-if-new.mjs
• scripts/publish-if-new.mjs: New 52-line Node script implementing idempotent publish logic

[coderabbitai]

Walkthrough

The release process is modified to use an idempotent publish guard. The scripts.release command in package.json replaces the direct npm publish call with a Node script scripts/publish-if-new.mjs. This new script checks the npm registry to verify whether the current package version is already published; if the version exists, it skips publishing; if the version is absent (detected via 404), it proceeds to publish with --access public --provenance flags. Non-404 errors are reported and cause the script to exit with a non-zero status.

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~20 minutes

Poem

🐰 A clever guard at publish's gate,
Checks the registry—is it too late?
Version found? We skip with care,
Missing version? Publish with flair! ✨
No duplicates in the registry, fair and square! 🎉

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title accurately describes the main change: adding idempotent behavior to the release publish step to prevent failures when republishing already-published versions.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

---

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

Actionable comments posted: 1

🤖 Prompt for all review comments with AI agents

Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@scripts/publish-if-new.mjs`:
- Around line 47-52: After calling spawnSync to run 'npm publish' in
scripts/publish-if-new.mjs (the block using spawnSync with cwd
resolve(.../packages/whisper) and assigning result), detect when the publish
fails (non-zero result.status) and perform a single read-after-write check by
invoking spawnSync('npm', ['view', `${name}@${version}`], ...) or equivalent to
query the registry for that exact package@version; if that check indicates the
version exists (success exit code / non-empty output) then treat the operation
as successful and exit 0, otherwise propagate the original publish failure exit
code. Ensure you reference the same cwd/stdio strategy and keep the extra npm
view call only on publish failure to avoid changing normal flow.

🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Run ID: 3b1ab817-1754-4e39-8cd2-25cef2ec8c81

📥 Commits

Reviewing files that changed from the base of the PR and between 9852432 and 34307b1.

📒 Files selected for processing (2)

• package.json
• scripts/publish-if-new.mjs

[wardbox]

Verified CodeRabbit's read-after-write suggestion against the current code — declining for this PR.

Why it's not needed:

1. release.yml:7-9 configures concurrency release-${{ github.ref }} with cancel-in-progress: false, so release runs are queued and serialized per branch. The concurrent-publish race the fix protects against is structurally impossible here.
2. With races ruled out, the only realistic way npm publish exits non-zero while the version lands on npm is a provenance attestation failure after the tarball uploads. CodeRabbit's suggested check would silently treat that as success and ship attestation-less releases — defeating the entire reason this repo uses direct npm publish instead of changeset publish (per the inline comment in release.yml: trusted publishing + provenance is the design intent).
3. The pre-write npm view already handles the legitimate idempotency case. Failures after that gate has passed should surface, not be papered over.