module: defer ESM bootstrap in pre-execution

[anonrig]

This change avoids initializing ESM on the default CJS startup path by registering lazy import/import.meta callbacks and only loading the ESM utils when needed. It keeps existing behavior intact (including loader-hook worker and worker/ShadowRealm paths) while reducing boot work for CJS-only runs.

• Lazy ESM initialization in lib/internal/process/pre_execution.js
• Make ESM utils initialization idempotent and lazily compute default conditions
• Export ESM callbacks for lazy delegation

Benchmark CI: https://ci.nodejs.org/view/Node.js%20benchmark/job/benchmark-node-micro-benchmarks/1795/

[nodejs-github-bot]

Review requested:

• @nodejs/loaders

[codecov]

Codecov Report

❌ Patch coverage is 95.23810% with 3 lines in your changes missing coverage. Please review.
✅ Project coverage is 89.74%. Comparing base (3819c7f) to head (6dd0383).
⚠️ Report is 10 commits behind head on main.

Files with missing lines	Patch %	Lines
lib/internal/modules/esm/utils.js	90.62%	3 Missing ⚠️

Additional details and impacted files

@@           Coverage Diff           @@
##             main   #61768   +/-   ##
=======================================
  Coverage   89.74%   89.74%           
=======================================
  Files         675      675           
  Lines      204642   204691   +49     
  Branches    39322    39332   +10     
=======================================
+ Hits       183657   183704   +47     
- Misses      13257    13278   +21     
+ Partials     7728     7709   -19     

Files with missing lines	Coverage Δ
lib/internal/process/pre_execution.js	97.86% <100.00%> (+1.90%)	⬆️
lib/internal/modules/esm/utils.js	98.80% <90.62%> (-0.70%)	⬇️

... and 41 files with indirect coverage changes

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[joyeecheung]

I don't think this is a good idea if we are moving towards better ESM support? Generally lazy initialization is reserved for "non essential paths that at least 50% of the application would not hit" (or if it's required mechanically due to cycles), but ESM is probably not going to be that..

[anonrig]

I think you're right @joyeecheung