Description

AI-agent disclosure: this PR was authored by an automated agent (Claude Code) and has not been line-by-line reviewed by a human before submission.

Switches every publish_package_* job in .github/workflows/build-status.yml from pnpm publish to npm stage publish. With staged publishing, CI uploads the tarball into a holding area on the registry instead of releasing it immediately — a maintainer then has to approve the staged version (with 2FA) before it becomes installable. End users still receive the same artifacts on npm, but the release step is no longer fully automated: there is now an explicit approval gate between a tag being pushed and the package going live. This is a follow-up to #7011 (which already removed the OTP prompt from the publish call); together they move the workflow toward npm's recommended staged-release flow.

Each publish job now:

• installs npm@latest so the runner-provided npm is upgraded before publishing — the stage subcommand landed in npm 11.15.0 and is not yet bundled with Node 24's default npm;
• runs both npm install -g and npm stage publish from the parent directory (cd ..), because the repo's package.json pins pnpm via devEngines and would otherwise block npm from executing inside the workspace;
• no longer needs the pnpm/action-setup step or the pnpm-specific --no-git-checks flag, both of which were dropped from the seven affected jobs.

Non-publish jobs were intentionally left alone and still install pnpm — only the release plumbing changes. Because the diff only touches the workflow file, there are no source, dependency, or published-artifact changes, no semver impact to flag, and no changeset to add; the new code path is exercised the next time a v* tag is pushed.

Checklist

— Don't delete this checklist and make sure you do the following before opening the PR

• I have a full understanding of every line in this PR — whether the code was hand-written, AI-generated, copied from external sources or produced by any other tool
• I flagged the impact of my change (minor / patch / major) either by running pnpm run bump or by following the instructions from the changeset bot
• I kept this PR focused on a single concern and did not bundle unrelated changes
• I followed the gitmoji specification for the name of the PR, including the package scope (e.g. 🐛(vitest) Something...) when the change targets a package other than fast-check
• I added relevant tests and they would have failed without my PR (when applicable)