Rename the packages to the @wantedly scope

[unblee]

WHY

Publishing to GitHub Packages requires the package name to carry the owner's scope.
This PR renames the six packages to the @wantedly scope and updates the in-repo references that have to follow.

It does not change the publish path itself.
That part is split into a follow-up PR touching only .github/workflows/release.yml, so this PR can be reviewed purely for whether the rename is complete.

WHAT

Renaming the packages

• Changed name of the six packages to the @wantedly scope and pointed publishConfig.registry at GitHub Packages

References updated to follow the rename

Build and lint fail unless the cross references inside the repository follow the rename to @wantedly/*.

• Updated the references in .prettierrc, eslint.config.mjs, the base.js / react.js of each config package, and packages/frolint/src
• Updated the unreleased changeset, which still pointed at the old names. Left as is, changesets cannot resolve the packages and the release fails
• Aligned the ESLint plugins' meta.name with the actual package names and updated the snapshots
• Updated the .scaffdog template and the reference in InstallCommand

CI

Unrelated to the rename and pre-existing, but included here because CI stays red after the rename without it.

• Added build to the lint job. The lint job was the only one that did not build first, so the main of eslint-plugin-wantedly (a build artifact) that the shared ESLint config loads did not exist and ESLint could not start
• Bumped actions/cache to v4

Merge order

Merge this PR first.
If the follow-up publish-path PR lands first, publishing to GitHub Packages fails with the unscoped names, the npm job behind it does not meet published == 'true' and is skipped, and the supply to npm that consumers still reference stops.

Note

No changeset is added here.
The renamed packages do not exist on GitHub Packages yet, so changeset publish publishes the current versions as they are.
That lets consumers keep the version unchanged when they switch names, which makes the migration easier.

[unblee]

Closing in favour of a different approach.

Renaming the packages in the tree breaks the consumers. Their lockfiles resolve the unscoped names from npm today. Once the names carry the @wantedly scope, a consumer cannot pick up a new version until it rewrites the name, and rewriting it points the lockfile at GitHub Packages, which asks for authentication even for a public package.

The rename also does not stop at name. The six packages reference each other by the old names, and so do the shared ESLint and Prettier configs, so those references have to move to @wantedly/ as well — while no package under that scope exists in any registry yet. Stripping the scope back off for the npm publish then has to reach the build output too, not just package.json.

The replacement leaves the tree, the lockfile and the published npm names exactly as they are on master, and scopes the manifests inside the release workflow instead, right before the publish to GitHub Packages. That reduces the whole migration to a single-file change in .github/workflows/release.yml, so neither this PR nor #1150 is needed.

The branch is left in place.