chore(pnpm): upgrade to pnpm 12.4.1

[gcko]

PR checklist

• Ensure you have added or ran the appropriate tests for your PR.
• DCO signed

What type of PR is this?

chore

What this PR does / why we need it:

Upgrades the repository from pnpm 11.1.1 to pnpm 12.4.1 with an exact, integrity-pinned release for local development and CI.

• Pins pnpm@12.4.1+sha512.<integrity> in js/package.json and records pnpm plus all 14 platform executables in the lockfile. Their versions, platform constraints, and SHA-512 integrity values match fresh npm registry metadata.
• Uses the native pnpm/setup GitHub Action at an exact commit. Every pnpm CI setup reads js/package.json and checks that the installed version matches it.
• Makes the local bootstrap provision the exact Corepack pin, updates developer documentation, and accommodates pnpm 12's two-document YAML lockfile in pre-commit.
• Preserves the application dependency lock document, including all 1,031 package records, unchanged from current main.

Release notes reviewed:

• 12.1: workspace task scheduling, install/linking changes, and side-effects cache configuration.
• 12.2–12.3: workspace linking fixes, credential redaction, registry routing, and stricter handling of explicitly configured minimum release ages.
• 12.4: six additional executable platforms and registry metadata cache keys that include the full registry URL. The first install refetches metadata; the package store remains reusable. Python/Cargo support and pipeline caching are opt-in; this repository continues using uv and its existing scripts.
• 12.4.1: filesystem copy fallbacks, symlink-target overwrite protection, workspace dependency links, and lifecycle scripts with effects outside the package directory.

No additional application or workspace configuration changes were needed for these releases.

Which issue(s) this PR fixes:

None.

Special notes for your reviewer:

Updated on top of main at 621a1bd5, including the merged dependency consolidation in #1550.

Validation completed locally with Node 26.5.0 and pnpm 12.4.1:

• CI=true pnpm install --frozen-lockfile with all three workspace node_modules directories removed (existing package store reused), then repeated successfully. The fresh install ran lifecycle scripts and installed the Husky hooks.
• pnpm lint:fix — 705 files checked; no fixes needed.
• pnpm type:check — root, UI, and Storybook passed.
• pnpm test — 4,444 passed, 5 skipped across 211 passing files.
• pnpm --filter @datarecce/ui build and pnpm run build.
• make install-frontend-requires — installed the pinned release without lockfile drift.
• actionlint -shellcheck= — workflow syntax passed.
• Parsed both lockfile YAML documents and compared the application document with the prior lockfile; verified registry integrity values for pnpm and every platform executable.
• Repository commit hooks passed with core.hooksPath=js/.husky/_ and Python pre-commit enabled.

Does this PR introduce a user-facing change?:

NONE

[iamcxa]

@gcko Reviewed at head 09db057d. Approving — no blocking findings (0 CRITICAL / 0 HIGH / 0 MEDIUM; 3 LOW, 2 NIT below, all fine as follow-ups).

Every integrity claim in the PR body was independently re-verified against the npm registry rather than taken at face value:

Check	Result
All 14 @pnpm/exe.*@12.4.1 integrity hashes vs registry dist.integrity	exact match, 0 mismatches
Lockfile platform set vs pnpm 12.4.1 optionalDependencies	identical — no extras, none missing
packageManager +sha512.<hex> vs registry tarball integrity	exact match
pnpm/setup@84cb39b2… vs the v2.0.2 tag	annotated tag dereferences to exactly that commit
package-json-file / install / cache / cache-dependency-path in action.yml @ pinned SHA	all four exist and are used correctly
Rollout completeness (git grep)	0 remaining pnpm/action-setup or "pnpm 11" references repo-wide
Application lockfile document	unchanged — 158 insertions / 0 deletions, purely a prepended document + ---
All 13 workflow YAML files parse	OK
Expression injection in new run: blocks	none — zero ${{ }} interpolation
CI at this head	green; log confirms the action resolved 12.4.1 from the +sha512. field and reported "No runtime requested … Skipping runtime install"

That last log line is what makes the release-ui.yaml step reorder safe: pnpm/setup installs no runtime, so actions/setup-node's npm 11.5.1+ for OIDC publishing is not shadowed.

Advisory findings (non-blocking)

1. LOW — 6 of 8 pnpm/setup call sites are unexercised by this PR's CI.
Only tests-js.yaml ran (lint, test-and-build). tests-python.yaml is path-filtered to recce/** / tests/** / pyproject.toml — none touched; release.yaml, release-ui.yaml, nightly.yaml, address-dependabot.yaml are tag / workflow_run / schedule only. release.yaml and release-ui.yaml are the publish path, so a break there surfaces at release time. Mitigated by the config being byte-identical across all eight sites, but a one-off workflow_dispatch dry-run of release-ui before the next release would close it cheaply.

2. LOW — tests-js.yaml:27 — store cache lost its restore-keys fallback.
The deleted actions/cache block had restore-keys: ${{ runner.os }}-pnpm-store-, so a lockfile change still warm-started from the prior store. pnpm/setup's cache: true keys on the lockfile hash; if it has no prefix fallback, every dependency bump now pays a cold store. Performance only.

3. LOW — tests-js.yaml:27, tests-python.yaml:78 — pnpm version becomes fork-PR-controlled.
Both run on pull_request; package-json-file: js/package.json lets a fork choose which pnpm binary CI downloads, where previously it was hardcoded version: 11.1.1. Blast radius is small — fork PRs get a read-only token and no secrets, and pnpm install --frozen-lockfile already executes fork-controlled lockfile content — but it is a genuine widening of the fork-controlled surface. Reasonable to accept; worth being a conscious decision rather than a side effect.

4. NIT — .pre-commit-config.yaml:9 — check-yaml now skips the lockfile entirely.
args: [--allow-multiple-documents] on the hook would keep YAML validation for js/pnpm-lock.yaml instead of dropping it. Multi-document is valid YAML, so the arg doesn't meaningfully weaken the other files.

5. NIT — Makefile:99 — corepack enable now runs unconditionally.
The previous line was a full no-op when pnpm was already on PATH. corepack enable writes shims into Node's bin directory and fails with EACCES on a system-managed Node, aborting make dev. Largely theoretical given the repo's nave convention.

---

Unusually well-evidenced dependency PR — the integrity pinning and the SHA-pinned action reading packageManager are a real improvement over the hardcoded version: they replace.

🤖 Reviewed with Claude Code