`packageManager` field is too limited

The packageManager field as currently designed is too limited for what I want to do:

• As a project author, I want to enforce a version range, like npm >= 10.0.0.

• As a project author, I want to control what happens when the developer uses a package manager that fails validation, either because it’s the wrong package manager or a version that’s outside of the defined range:

  • Should it warn, but then proceed
  • Should it warn, and then prompt to download the newest supported version, and then try again in that version
  • Should it error, and exit (like engines.strict)

• As a project author, I want to control over package managers based on operations. For example, I want to ensure that install commands use the package manager I specify, but run commands can use any package manager. (So install via pnpm and run scripts via Bun, for example.)

Seeing as this much complexity will require multiple configuration options, I suggest we retire the packageManager field and create a new corepack field that can contain a configuration object with all the necessary fields to cover the various permutations described above.

@nodejs/corepack @nodejs/loaders @nodejs/npm @nodejs/package-maintenance

No files or tests are named. Start by locating the existing packageManager validation and configuration entry points in Corepack, then trace how install and run operations are dispatched. Done means an agreed configuration model covers version ranges, invalid-manager behavior, and per-operation policy.