Allow retrying npm publish for an existing release tag #82

Problem / Use case

In .github/workflows/release.yml, release-please creates the git tag and GitHub Release before npm publish runs. If npm publish fails, re-running the workflow does not retry it: release-please sees that the release already exists, reports release_created as false, and skips the publish steps.

This already happened with 1.5.0 (#32). The tag was deleted to force a retry, which corrupted release-please's baseline: the manifest no longer matched any tag, release-please proposed a bogus 1.5.0 → 1.3.1 downgrade, and a revert PR was needed.

Also, the publish steps run npm run bundle again before npm publish, so the npm tarball is rebuilt instead of being exactly what was tagged and what plugin users already received from git.

Proposed solution

Restructure release.yml so that publishing can be retried for an existing tag:

1. Split publishing into its own publish job.
   • It runs after release-please when release_created == 'true', checking out the new tag (tag_name output).
   • It can also run on workflow_dispatch with a required tag input (for example deploygate--v1.5.2). In that case the release-please job is skipped.
2. Keep everything in release.yml. npm trusted publishing is configured per workflow file, so a separate workflow file would not be allowed to publish.
3. Publish exactly what was tagged:
   • Check out the tag and run npm ci.
   • Do not run npm run bundle before npm publish. The committed plugin/scripts/bundle.js at the tag is published as-is, so npm and git always ship the same file.
4. Add guards before publishing:
   • Validate the tag format (deploygate--vX.Y.Z).
   • Check that the version in package.json at the tag matches the tag.
   • Skip with a clear message if that version already exists on npm.
5. Document the retry procedure in the README "Releasing" section: Actions → Release → Run workflow → enter the tag.

Alternatives considered

• A separate publish.yml workflow: simpler to read, but npm trusted publishing would reject it unless the npm package settings were changed too.
• Deleting and recreating the tag: this is what broke the release-please baseline in chore: revert deploygate 1.5.0 release to restore 1.4.0 released state #32.
• Publishing manually from a laptop: loses provenance and depends on a personal npm token.

Additional context

Found while reviewing the release process after 1.5.2 (#80). Related: #81 (bundle freshness check on release PRs) makes sure the committed bundle that this job publishes is up to date.