Restore node module resolution so the frontend typecheck passes

The TypeScript 7 tsconfig migration in 23d130b and 2984b2f set
config/tsconfig.base.json to `module: node16` / `moduleResolution: node16`
in place of the `commonjs` / `node` pair this fork inherited. That left
`tsc -p config/tsconfig.build.json` — the gate hanzo.yml runs — failing
with 398 errors, the bulk of them:

  static/app/actionCreators/modal.tsx(61,28): error TS2307: Cannot find
  module 'sentry/components/modals/emailVerificationModal' or its
  corresponding type declarations.

Nothing is missing. emailVerificationModal.tsx sits next to its sibling
modals and the `sentry/*` alias points at static/app. node16 grades each
import separately: static imports in these files are read as CommonJS and
resolve, but `import()` is always read as ESM, where a bare directory and
an absent file extension are both errors. The route table and every
lazily loaded modal are written with `import()`, which accounts for all
333 TS2307s and the 9 TS2835s. The same CJS/ESM split produced the 21
TS1479s and 21 TS2305s: node16 honors package `exports` and lands on
different type entry points for marked, screenfull and rrweb.

Webpack resolves this code, through `resolve.alias` in webpack.config.ts,
and webpack has no such modes, so `moduleResolution: node` is what
describes it. Restoring it takes the gate from 398 errors to 0.
`moduleResolution: bundler` also describes webpack and would stay legible
to TS7, but it reads `exports` the way node16 does and leaves 9 genuine
type errors in the rrweb and emotion overlay types; that is a code change
and is not attempted here. `downlevelIteration` stays dropped, it does
nothing at target ES2022.

config/tsconfig.base.json

@@ -14,9 +14,17 @@
     //
     // [0]: https://babeljs.io/docs/en/babel-preset-typescript
     // [1]: https://node.green
-    "module": "node16",
+    //
+    // `moduleResolution` must describe webpack, which is what actually resolves
+    // these files (see `resolve.alias` in webpack.config.ts). node16 does not:
+    // it splits resolution into CJS and ESM modes, and every `import()` in a
+    // .tsx file is graded in ESM mode, where a bare directory and a missing
+    // file extension are both errors. The whole route table and every lazy
+    // modal is written that way, so node16 reports ~330 phantom "cannot find
+    // module 'sentry/...'" on files that are sitting right there.
+    "module": "commonjs",
     "target": "ES2022",
-    "moduleResolution": "node16",
+    "moduleResolution": "node",
 
     // We add esnext to lib to pull in types for all newer ECMAScript features
     "lib": ["esnext", "dom"],