chore(deps): adopt pnpm catalogs for single-version dependency policy #488

Context

We want clearer dependency ownership and a single-version policy across the monorepo, especially after aligning the Next apps and enabling React Compiler.

Reference: https://antfu.me/posts/categorize-deps

The useful pattern from the article is to use pnpm catalogs / named catalogs in pnpm-workspace.yaml so workspace package manifests can say catalog:<name> instead of repeating literal versions everywhere. That gives us both centralized version control and dependency category context during reviews.

Scope

• Introduce pnpm catalogs in pnpm-workspace.yaml for shared dependency families.
• Start with high-churn / policy-sensitive families, for example:
  • frontend: React, React DOM, Next.js, React Compiler tooling, UI/runtime frontend packages.
  • build: TypeScript, Nx, Vite/Rolldown/SWC/build tooling.
  • lint: Biome, ESLint, Ultracite, lint plugins/configs.
  • test: Vitest, Playwright, Testing Library, MSW, test utilities.
  • types: @types/* packages where a single version policy matters.
  • backend: Medusa/Payload/server runtime packages if they benefit from centralization.
• Replace duplicated literal versions in workspace package manifests with catalog references where safe.
• Keep runtime dependencies vs devDependencies semantics intact; catalogs should categorize version ownership, not change install/runtime behavior.
• Add a short dependency policy note explaining when to add a package to which catalog.
• Consider adding tooling enforcement after migration, for example eslint-plugin-pnpm catalog rules or a lightweight custom check.

Non-Goals

• Do not combine this with the Next 16.3 alignment PR (chore(next): align all Next apps on Next.js 16.3 #484).
• Do not combine this with the Rust React Compiler PR (chore(next): switch Next apps to the Turbopack Rust React Compiler #485).
• Do not upgrade package versions unless needed to converge existing duplicate versions.

Acceptance Criteria

• Common duplicated dependency versions are represented through pnpm catalogs.
• Package manifests use catalog: / catalog:<name> for migrated dependencies.
• The lockfile is regenerated cleanly with pnpm.
• Local workspace install validation passes with pnpm install --lockfile-only --frozen-lockfile after regeneration.
• A short repo note documents the catalog categories and single-version policy.