chore(pnpm): pin pnpm@10.34.5 and move pnpm.* settings to workspace/policy

[pyramation]

Part of standardising pnpm across the four platform repos. This is the highest-risk of the set — the ignored keys here are the whole Graphile v5 stack.

The bug

pnpm 11 stopped reading the pnpm field in package.json:

[WARN] The "pnpm" field in package.json is no longer read by pnpm.
       The following keys were ignored: "pnpm.overrides"

It warns, it does not fail — the install exits 0 and all four key groups quietly stop applying:

key	entries	what it holds
overrides	16	the Graphile v5 set + graphql single-copy + a @smithy pin
publicHoistPattern	1	@jest/test-sequencer hoist
packageExtensions	1	jest-config
onlyBuiltDependencies	2	@launchql/protobufjs, core-js-pure

Two of the overrides are doing load-bearing work:

• graphql: 16.13.0 — the single-copy guard. Two copies of graphql in one tree produce Cannot use GraphQLSchema "[object GraphQLSchema]" from another module or realm at runtime. grafast, graphile-build, graphile-build-pg and @dataplan/* are resolved as a set and break across minors.
• @smithy/node-http-handler: <4.5.0 — a pin away from a known-bad release.

Nothing fails at install. It fails on the next re-resolution — a new dep, pnpm up, or --no-frozen-lockfile in an image build — and surfaces far from the cause.

This is not hypothetical: a local install on pnpm 11 in this repo produced a regenerated lockfile with the overrides: block missing entirely. The versions happened to still be right; the constraint was simply gone.

What changed

• overrides / publicHoistPattern / packageExtensions → pnpm-workspace.yaml. pnpm 10 already honours them there (constructive-db runs this on 10.34.5), so it is correct today and forward-compatible with 11 — no flag day when we upgrade.
• onlyBuiltDependencies → pnpm-policy.yaml allowBuilds, regenerated via pnpm-policy generate rather than hand-edited, since that key is tool-managed.
• packageManager: pnpm@10.34.5; workflows pnpm/action-setup@v2 → v4 (7 call sites) and their version: 10 removed.

On that last point: a bare version: 10 floats to the newest 10.x at run time, so CI could move with no commit — and v2 ignores packageManager entirely, so local and CI had no way to agree. v4 reads packageManager when no version input is given, making it the single source of truth.

The lockfile is deliberately untouched

pnpm install --frozen-lockfile passes against the committed lockfile with the new config, and its overrides: block is byte-identical — resolution is unchanged.

A full re-resolve additionally prunes ~1530 stale package entries (−7065 lines). That is real, but unrelated to this change and too large to bury in a version pin; worth its own PR.

Verification

$ pnpm --version
10.34.5
$ pnpm pnpm-policy check
pnpm-workspace.yaml matches the policy
$ pnpm install --frozen-lockfile --lockfile-only
Scope: all 118 workspace projects
Done in 261ms using pnpm v10.34.5

The lockfile records all 16 overrides plus a packageExtensionsChecksum, so the pins are demonstrably in force, not merely present. Both edited workflows validated as parsing YAML.

🤖 Generated with Claude Code

https://claude.ai/code/session_01V6watrJsLurfsr3uhnqibB

[pyramation]

Correction: the lockfile is not stale

Earlier I noted a full re-resolve prunes ~1530 package entries (−7065 lines) and suggested that was real staleness worth its own PR. That was wrong, and I want to correct it before anyone acts on it.

That diff was an artifact of pnpm install --lockfile-only, which resolves without the full tree context. A real install produces a byte-identical lockfile:

$ rm -rf node_modules && pnpm install
Packages: +1433
Progress: resolved 1433, reused 1366, downloaded 29, added 1433, done
Done in 4.7s using pnpm v10.34.5

$ git status --porcelain pnpm-lock.yaml
                      # empty — unchanged

So there is no lockfile cleanup pending, and none should be done: committing that prune would have removed 1,433 legitimate entries. Leaving the lockfile untouched in this PR is correct on its own merits, not just for reviewability.

What was genuinely broken: node_modules, not the lockfile

The ERR_PNPM_ABORTED_REMOVE_MODULES_DIR_NO_TTY seen while testing came from a store/layout mismatch, since the tree had been built by pnpm 11:

	before	after
packageManager	pnpm@11.11.0	pnpm@10.34.5
storeDir	store/v11	store/v10

Purging and reinstalling on 10.34.5 resolves it. Worth knowing for anyone who ran an install here on 11 — they will need rm -rf node_modules once after this merges. The shared store is separate and unaffected, so the reinstall is nearly all hardlinks (29 downloads out of 1433).

Post-cleanup checks on this branch: pnpm exec tsc --version → 5.9.3, and pnpm pnpm-policy check → "pnpm-workspace.yaml matches the policy".