Publish to GitHub Packages and keep publishing to npm

[unblee]

WHY

Releases to npm are currently published with a granular access token.
That token has to be rotated every 90 days, and the release stops once it expires.
Moving the publish target to GitHub Packages removes the problem.

Consumers still reference the old names on npm, so publishing to npm continues during the migration period.

This PR touches only .github/workflows/release.yml.
The package rename and the references that follow it live in the base PR.

WHAT

The release job is split in two.

create-release-pr (publish to GitHub Packages)

• After the build, runs actions/setup-node again with registry-url: https://npm.pkg.github.com and scope: "@wantedly", then publishes through changesets/action
• It is placed after install because putting it earlier would point the resolution of public dependencies at GitHub Packages as well
• Authentication uses the GITHUB_TOKEN that Actions issues per job. This repository has default_workflow_permissions: write, so packages: write is granted as long as no permissions: block is written
• Passes outputs.published to the job behind it

release-to-npm (publish to npm)

• Triggered by needs: create-release-pr and if: needs.create-release-pr.outputs.published == 'true'
• Strips the scope with grep -rl '@wantedly/' | xargs sed, rewrites the registry to npmjs with jq, and publishes with lerna publish from-package
• The stripping covers the build artifacts as well as package.json. Files such as packages/frolint/lib/utils/prettier.js require the scoped names, so restoring only the name in package.json would ship a broken package to npm
• Authentication uses secrets.NPM_TOKEN

What to look at in review

• set -euo pipefail is there because grep -rl exits 1 when it matches nothing, which would otherwise let the whole pipe count as a success and publish scoped names to npm as a brand new package without restoring them
• git commit --no-verify is used because husky's pre-commit runs ESLint through lint-staged, and it always fails right after the scope has been stripped since the config files can no longer be resolved
• The publish order is GitHub Packages first, npm second. The other way round, a failure on the unverified GitHub Packages path would also stop the existing supply to npm
• No permissions: block is added. The repository default (default_workflow_permissions: write) grants the necessary scopes. Being explicit would take contents: write, pull-requests: write and packages: write, but publish only runs on master and cannot be verified by a PR check, so missing one would only surface after the merge. Whether to be explicit is left to the reviewer

Merge order

Merge the base PR (the rename) first.
If this PR lands first, publishing to GitHub Packages fails with the unscoped names, the release-to-npm job does not meet published == 'true' and is skipped, and the supply to npm that consumers still reference stops.

Note

Publish only runs after a merge to master, so this job layout cannot be verified by a PR check.
The first release after the merge is the only real verification.

[unblee]

Closing in favour of a different approach, together with its base #1149.

Scoping the package names in the tree breaks the consumers, so the rename is dropped and the manifests are scoped inside the release workflow instead, right before the publish to GitHub Packages. Only name, publishConfig.registry and repository are rewritten, on the runner, and the commit that carries them never leaves it.

With the rename gone, the npm side no longer has to be moved into a second job either: the existing changesets/action job stays byte-identical to master and keeps owning the version bump, the tags and the npm publish, and the GitHub Packages publish is added behind it.

See #1149 for the reasoning. The branch is left in place.