chore: pin pnpm to exact version 12.4.2

[dinwwwh]

Pins pnpm to exactly 12.4.2 in devEngines.packageManager instead of the ^12.4.1 range, and records 12.4.2 in pnpm-lock.yaml, the same change as middleapi/orpc#2036. With a range, Corepack 0.36.0+ resolves the newest pnpm on npm, and pnpm does not switch to the lockfile's version when Corepack starts it, so every new 12.x release made pnpm install --frozen-lockfile fail with ERR_PNPM_FROZEN_LOCKFILE_WITH_OUTDATED_LOCKFILE until the lockfile was refreshed.

Behavior

• Corepack always runs the pinned pnpm, so new pnpm releases no longer break frozen installs.
• Running any other pnpm 12.x locally still switches to the pinned version, as before.
• Upgrading pnpm is an explicit change: set the new version in devEngines.packageManager.version, then run pnpm install --lockfile-only.
• The lockfile diff only touches the packageManagerDependencies block and the pnpm / @pnpm/exe.* entries.

Testing

• With Corepack 0.36.0, CI=true and cold caches, pnpm install --frozen-lockfile fails on main with ERR_PNPM_FROZEN_LOCKFILE_WITH_OUTDATED_LOCKFILE and passes on this branch with pnpm 12.4.2.
• With the exact pin set one release behind npm (12.4.1 while 12.4.2 is out), the same Corepack install passes with 12.4.1, and pnpm 12.4.2 started without Corepack switches to 12.4.1.
• eslint and sherif pass.

[pkg-pr-new]

• @standard-server/hono-node-playground
• @standard-server/node-http-playground

@standard-server/aws-lambda

npm i https://pkg.pr.new/@standard-server/aws-lambda@95

@standard-server/core

npm i https://pkg.pr.new/@standard-server/core@95

@standard-server/fastify

npm i https://pkg.pr.new/@standard-server/fastify@95

@standard-server/fetch

npm i https://pkg.pr.new/@standard-server/fetch@95

@standard-server/node

npm i https://pkg.pr.new/@standard-server/node@95

@standard-server/peer

npm i https://pkg.pr.new/@standard-server/peer@95

@standard-server/shared

npm i https://pkg.pr.new/@standard-server/shared@95

commit: 9d46baf

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!

[codspeed]

Merging this PR will not alter performance

✅ 26 untouched benchmarks
⏩ 108 skipped benchmarks¹

---

_{Comparing chore/pnpm-12-4-2 (9d46baf) with main (466adb3)²}

Footnotes

1. 108 benchmarks were skipped, so the baseline results were used instead. If they were deleted from the codebase, click here and archive them to remove them from the performance reports. ↩

2. No successful run was found on main (eeda6b7) during the generation of this report, so 466adb3 was used instead as the comparison base. There might be some changes unrelated to this pull request in this report. ↩

[pullfrog]

✅ No new issues found.

Reviewed changes

• Pin pnpm to exact 12.4.2 — devEngines.packageManager.version changes from the ^12.4.1 range to the exact 12.4.2, making pnpm upgrades explicit and stopping Corepack from resolving the newest 12.x release out from under a frozen lockfile.
• Lockfile re-provisioned — pnpm-lock.yaml updates the packageManagerDependencies.pnpm specifier/version and the pnpm plus 14 @pnpm/exe.* package and snapshot entries to 12.4.2; the diff is confined to those blocks as the body describes.

The lockfile specifier matches package.json exactly and the regenerated sections are internally consistent. The repo has no other pnpm version reference: every workflow uses pnpm/action-setup@v6 without a version input, and there is no .npmrc, .node-version, .tool-versions, mise.toml, Dockerfile, or doc mentioning a pnpm version. No actionable findings.

ℹ️ Node 26 matrix leg is red on an unrelated step

test_node_matrix (26) failed at pnpm runtime set deno 2, before pnpm i ran. The other three legs (20/22/24) executed the same pnpm 12.4.2 and the same step successfully, so this is not attributable to the version pin.

Technical details

# Node 26 leg fails during runtime provisioning

## Affected sites
- `.github/workflows/ci.yaml:41` — `pnpm runtime set deno 2` fails only on the Node 26 leg (job 105063143439); the subsequent `pnpm i` and `pnpm run test:coverage` steps are skipped.

## Required outcome
- None for this PR — re-running the leg should confirm the known deno-provisioning flake.

## Open questions for the human (optional)
- Is deno provisioning flaky enough to warrant a retry around `pnpm runtime set deno 2`?

  ^{｜ View workflow run ｜ Using DeepSeek Flash (default — pick a model for stronger reviews) ｜ 𝕏}