Dynamic "import" creates a race condition with initial load requests

### Verify canary release - [X] I verified that the issue exists in the latest Next.js canary release ### Provide environment information > This issue is not related to the precise Next version but rather to the `with-msw` example code. Operating System: Platform: darwin Arch: arm64 Version: Darwin Kernel Version 21.6.0: Wed Aug 10 14:28:23 PDT 2022; root:xnu-8020.141.5~2/RELEASE_ARM64_T6000 Binaries: Node: 16.13.2 npm: 8.1.2 Yarn: 1.22.17 pnpm: 7.4.0 Relevant packages: next: 12.3.4 eslint-config-next: N/A react: 17.0.2 react-dom: 17.0.2 ### Which example does this report relate to? with-msw ### What browser are you using? (if relevant) _No response_ ### How are you deploying your application? (if relevant) _No response_ ### Describe the Bug - Originally reported in https://github.com/mswjs/msw/issues/1474 (I describe what/why happens [here](https://github.com/mswjs/msw/issues/1474#issuecomment-1323491118)). I believe due to #25607, MSW example has migrated from `require()` to dynamic imports `import()` in order to tree-shake MSW from production builds. That, however, introduced a different problem: - Since `await import()` is async, and there's no top-level `await` to wait for the `initMocks()` function, there's a race condition created between the client-side code and the mocks being imported. This race condition manifests upon initial page requests as those may be ignored by MSW since the code is not done resolving `await import()` when those requests happen. ### Expected Behavior 1. The example imports/requires MSW setup _synchronously_. 2. Alternatively, the example ensures that the app doesn't run until MSW is imported. This import is not a costly operation, it's just a matter of asynchronicity and awaiting it. 3. _Side-effect:_ MSW must not be included in the production bundle as an indirect result of this fix/change. ### To Reproduce - See the reproduction repo in https://gi…