fix(deps): move pnpm settings out of package.json into pnpm-workspace.yaml

[oc-tmueller]

The failure

The JS Unit job on #628 dies at make test-js before a single spec runs:

npx --yes pnpm@10 install --frozen-lockfile && touch node_modules
 ERR_PNPM_LOCKFILE_CONFIG_MISMATCH  Cannot proceed with the frozen installation.
 The current "overrides" configuration doesn't match the value found in the lockfile
make: *** [Makefile:95: node_modules] Error 1

Dependabot's regenerated pnpm-lock.yaml has no overrides: block, while package.json still declares 21 overrides.

Root cause

pnpm >= 11 no longer reads the pnpm field in package.json — those settings moved to pnpm-workspace.yaml:

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

Dependabot has moved to such a pnpm; the Makefile pins pnpm@10, which does still read the field. The two disagree about the effective configuration, so Dependabot resolves without the overrides and the frozen install rejects the result.

Reproduced by re-running the resolution locally against dependabot/npm_and_yarn/minor-and-patch-96b5e73bd6:

resolution	overrides: in lock	vs. Dependabot's lock on #628
pnpm@10 install --lockfile-only	present	225 / -378 lines different
pnpm@11 install --lockfile-only	absent	byte-identical
pnpm@12 install --lockfile-only	absent	byte-identical

So this is not a one-off bad Dependabot run — it will break every future Dependabot pull request here. The uglier half is invisible in CI: under pnpm >= 11 the 21 transitive pins added in #605 to close the Dependabot alerts do not apply at all. Today only minimatch and picomatch actually resolve elsewhere, and to newer versions rather than vulnerable ones, but the floor those pins are supposed to provide is gone.

The change

Move pnpm.overrides and pnpm.peerDependencyRules into pnpm-workspace.yaml, which pnpm 10, 11 and 12 all read. Nothing else changes — in particular pnpm-lock.yaml is untouched, because the existing lockfile is already correct for this configuration.

Verification

• pnpm@10 install --frozen-lockfile (the exact command from Makefile:95) passes, with pnpm-lock.yaml left unmodified.
• pnpm 12 on the unchanged lockfile: Lockfile is up to date, resolution step is skipped.
• pnpm 10, 11 and 12 each regenerate a byte-identical lockfile from this configuration, so Dependabot and CI will stop fighting over it.
• The move is resolution-neutral: regenerating the lockfile with pnpm@10 before and after the move yields identical files.
• pnpm vite build reproduces the committed bundle unchanged.

tests/js/karma.config.cjs needs a surrounding core checkout, so the specs themselves were not run locally — but the failure is entirely in the install step and the resolved tree is unchanged, so CI on this PR exercises the real thing.

Follow-ups

• chore(deps-dev): bump vue from 3.5.40 to 3.5.42 in the minor-and-patch group across 1 directory #628 needs @dependabot recreate once this lands, so it regenerates its lockfile with the overrides in place.
• The 4.2 branch has the same config and already merged its equivalent bump (chore(deps-dev): bump vue from 3.5.40 to 3.5.42 in the minor-and-patch group #629) with the overrides stripped, since it has no JS Unit job to catch it. Its tip is broken today. Handled separately.
• Unrelated to this PR, but noted while testing: pnpm >= 11 also hard-errors with ERR_PNPM_IGNORED_BUILDS: esbuild, and a full install (not a --lockfile-only one) writes an allowBuilds: stub into pnpm-workspace.yaml. Harmless while the Makefile pins pnpm@10; it will need an explicit build-script decision whenever that pin moves.