fix: pnpm settings survive the pnpm 11 bump

[stxkxs]

Four CVE floors were about to be dropped on the floor by a routine package-manager bump.

What happens without this

pnpm 11 does not read the pnpm field in package.json, and it does not fail when it finds one. It prints

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

…and installs anyway. That warning is already in this repo's CI log on #27, the pending pnpm 10 → 11 bump. Upstream tracks the silent-ignore behaviour as security-affecting: pnpm/pnpm#11536.

osv-scanner is a required check here and would have caught the CVE-driven floors coming back. The one it would not catch is nanoid: ^3.3.17 — the caret, not the floor, is the load-bearing part. >=3.3.17 resolves to nanoid 6, which is ESM-only and is not the API postcss calls. OSV has no opinion on a compatibility pin, so that one goes through silently and surfaces later as a build failure with no obvious cause.

Why now and not with the bump

pnpm 10.32.1 already reads pnpm-workspace.yaml. Verified locally, not assumed. Landing the move first means there is no window in which the settings are read from neither place, and it leaves #27 as a pure package-manager bump.

onlyBuiltDependencies → allowBuilds is a different story — pnpm 10 silently ignores allowBuilds — so that rename has to happen with a bump, not before. This repo has no build-script settings, so it does not apply here.

What the move buys beyond correctness

Each floor now carries its advisory and the reason for its exact form: why fast-uri is >=4.1.2 and not the 3.x patch level, why js-yaml is scoped to the 4 line so astro's own 5.x parser is left alone, why nanoid is a caret. All of that was in commit bodies and none of it was in the file. JSON had nowhere to put it.

Verification

• Positive — pnpm install --lockfile-only after the move produces a lockfile byte-identical to main.
• Anti-vacuity — that only means something if the command can move the lockfile at all. With the overrides removed, the same command downgrades fast-uri 4.1.2 → 3.1.5 and rewrites the overrides: block. So "identical" means the floors are still applied, not that nothing re-resolved.
• pnpm lint exits 0.
• Lockfile unchanged ⇒ osv-scanner sees the same input as main.

Note on #27

Its remaining failure is unrelated to this: pnpm 11 changed the minimumReleaseAge default from 0 to 1440, and nanoid@3.3.18 published inside that window. It clears on its own once the package is 24h old. Merging this moves main, which rebases #27 and re-runs its checks.