This PR refactors `exit-handler.js` to be a class so that it can more
easily track its internal state. It uses this state to now fully
distinguish between 3 states: npm never being set, npm not loaded, and
exit handler never called. There are some new error messages shown via
console.error if we know we are in an unexpected state.

This also continues the refactoring started in #7415 to separate
concerns between `npm` and `CLI`. Identifying the error message and
logging it have been move to `npm` but catching that error and setting
the `process.exitCode` are still handled in `exit-handler.js` and
`cli/entry.js`.

It also moves `command.cmdExec` to `npm` since it never called from
within any `command` instance. This lets `npm` only ever call
`command.exec` or `command.workspaceExec` now.

npm 9/10 在 docker 内长期存在 'Exit handler never called' bug
(npm/cli#7415, #6995),即使 exit code 0 也会导致依赖装不全。

改用 pnpm 9 (corepack 启用):
- 内容寻址 + 全局 store,避免 hardlink 在 docker 沙盒里的 race
- 自动从 package-lock.json 导入依赖关系 (pnpm import)
- 在 GitHub Actions / GitLab CI 上稳定性远好于 npm
- 等待 npm 11+ 修复后可以再切回去

npm 9/10 在 docker 内长期存在 'Exit handler never called' bug
(npm/cli#7415, #6995),即使 exit code 0 也会导致依赖装不全。

改用 pnpm 9 (corepack 启用):
- 内容寻址 + 全局 store,避免 hardlink 在 docker 沙盒里的 race
- 自动从 package-lock.json 导入依赖关系 (pnpm import)
- 在 GitHub Actions / GitLab CI 上稳定性远好于 npm
- 等待 npm 11+ 修复后可以再切回去