Adopt pnpm catalogs for devDependencies (#93071)
### What?
Adopt pnpm [catalogs](https://pnpm.io/catalogs) for shared hoisted devDependencies: `typescript`, `jest`, `eslint`, and `prettier`. Each is pinned once in `pnpm-workspace.yaml` and referenced as `"<name>": "catalog:"` by every consumer.
Also adds the missing `dom.iterable` lib to `@next/routing`'s tsconfig, required by `URLSearchParams.entries()` in TypeScript 6.
### Why?
Several packages invoke these binaries in their build, test, or lint scripts but do not declare them in their own `devDependencies` — they rely on the hoisted root install.
This breaks Turborepo's cache invalidation: without a declared dep, a package has no lockfile edge to the tool, so bumping its version (e.g. #91257's TypeScript 5 → 6 upgrade) does not invalidate that package's task hash. `@next/routing`'s `types` task has been a remote-cache hit on canary since the TS 6 bump, even though it now fails locally on a cold cache — CI is replaying a stale pre-bump success.
The same latent hazard exists for `jest` (`@next/codemod`), `eslint` (`@next/bundle-analyzer-ui`), and `prettier` (`create-next-app`).
### How?
- `pnpm-workspace.yaml` defines `catalog:` entries for each tool.
- Consumer packages declare `"<name>": "catalog:"`. pnpm still hoists one copy, but each consumer now has a real lockfile edge to the resolved version.
- Root `package.json` migrates each pin to `"catalog:"` so the workspace file is the single source of truth.
Turborepo needs no changes — its existing per-package hashing picks up lockfile edge changes automatically. Future catalog bumps will invalidate every consumer's cache.
`@types/node` is a deliberate omission from this round: several packages intentionally pin different majors (`^22`, `^20`, `20.14.2`), so migrating it needs per-package intent review rather than bulk conversion.
<!-- NEXT_JS_LLM_PR -->
