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 package.json passes.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!

[pullfrog]

✅ No new issues found.

Reviewed changes

• Exact pnpm pin — package.json devEngines.packageManager.version moves from the ^12.4.1 range to the exact 12.4.2, so Corepack resolves a fixed release instead of the newest matching 12.x.
• Lockfile refresh — pnpm-lock.yaml packageManagerDependencies.pnpm now records specifier/version 12.4.2, with every pnpm@ / @pnpm/exe.*@ entry and its integrity hash bumped accordingly.

Verified on 16bc7ae: CI=true pnpm install --frozen-lockfile reports "Lockfile is up to date, resolution step is skipped" and exits 0 on pnpm 12.4.2 with a clean tree, all 15 pnpm/exe integrity hashes match registry.npmjs.org, and both Corepack and pnpm/action-setup@v6 consume devEngines.packageManager as the PR describes. The exact pin is the documented Corepack remedy for range drift, and the trade-off (manual, explicit upgrades) is called out in the PR description.

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