No packageManager pin: contributors on a different pnpm major regenerate pnpm-lock.yaml incompatibly (drops security overrides)

[debugmcpdev]

Summary

package.json has no packageManager field. Both first-time contributors this week hit the consequences from opposite directions:

• One reported pnpm install --frozen-lockfile failing with ERR_PNPM_LOCKFILE_CONFIG_MISMATCH (overrides drift) and correctly reverted the lockfile out of their diff (fix(breakpoints): clear the provisional message once a breakpoint verifies #476).
• The other committed the regenerated lockfile: it removed the entire overrides block — the security floors for vite, path-to-regexp, brace-expansion, hono, fast-uri, qs, ip-address, esbuild — and downgraded esbuild 0.28.2 → 0.27.7 (Fix: Clear provisional js-debug breakpoint message when verified #473/Fix: Make dev-proxy build timeout configurable and distinct from failures #474/Fix: Explicit adapterConfig attach allow-lists and did-you-mean suggestions #475).

A different pnpm major computes the lockfile's recorded settings differently, so --frozen-lockfile mismatches and a plain pnpm install rewrites the file destructively. Nothing in the repo tells the contributor (or their tooling) which pnpm to use; CI happens to use version: 10 in pnpm/action-setup and the Dockerfile pins pnpm@10.33.0, but a local clone gets whatever is installed.

Fix

1. Add "packageManager": "pnpm@10.33.0" to package.json. pnpm's package-manager-strict default then gives a clear error when the wrong major is used, and corepack users get auto-switched.
2. Remove the version: 10 input from pnpm/action-setup in the four workflows that set it (ci.yml, flake-hunt.yml, mem-bench.yml, release.yml) — the action reads packageManager when the input is omitted, and errors if both are specified and differ.
3. CONTRIBUTING.md: note the pin, corepack enable, and "never commit a regenerated pnpm-lock.yaml".

Dockerfile already matches (10.33.0) — keep it in lockstep when bumping.