feat(compile): support module.register() and module.registerHooks() in compiled binaries - #33853

Add a loader resolve hook system to the checkin test infrastructure:
- `ops_loader.rs`: `op_loader_register_resolve` op that registers
  specifier-to-URL resolve mappings
- `loader.ts`: `checkin:loader` JS module exposing `registerResolveMapping`
- `TypescriptModuleLoader`: checks resolve mappings and returns
  `ModuleResolveResponse::Async` to exercise the async resolution path
- `loader_resolve` integration test: registers a virtual specifier,
  dynamically imports it, and verifies the module loads correctly

Co-Authored-By: Claude Opus 4.6 <[email protected]>

Resolve conflicts in recursive_load.rs and map.rs by combining
main's refactored resolve caching (resolved_specifier field,
accessor methods, resolve_root_from_init) with the async module
resolution support (ModuleResolveResponse).

Co-Authored-By: Claude Opus 4.6 <[email protected]>

Change ModuleLoader::resolve to return ModuleResolveResponse (Sync/Async)
instead of a plain Result, enabling loaders to perform async resolution.

Per review feedback, omit the panicking `into_result()` helper. Instead,
callers use explicit match or the `resolve_sync`/`resolve_async` methods
on ModuleMap. Loaders with async resolve must override import_meta_resolve.

Co-Authored-By: Claude Opus 4.6 <[email protected]>

Add a message-passing bridge between the Rust module loader and JS hook
functions, matching Node.js `module.register()` customization hooks API.
Hooks use async functions with `resolve(specifier, context, nextResolve)`
and `load(url, context, nextLoad)` signatures.

Co-Authored-By: Claude Opus 4.6 <[email protected]>

…resolve

- Remove duplicate `use deno_error::JsErrorBox` in recursive_load.rs
  that caused build failures (error[E0252])
- Remove `ModuleResolveResponse::into_result()` per review feedback —
  it panics on async responses which is risky
- Change `import_meta_resolve` default to use `resolve_import` directly
  instead of going through `resolve().into_result()`
- Update test to match on `ModuleResolveResponse::Sync` explicitly
- Run formatter on core_testing files

- Use #[derive(Default)] instead of manual impl
- Remove useless .into() on JsErrorBox

… test

- Remove unused import of `ModuleLoaderError` in source_map.rs (clippy)
- Restore import_meta_resolve default to call self.resolve() for Sync
  results, falling back to resolve_import() only for Async. The previous
  change broke import.meta.resolve() for loaders (like EmbeddedModuleLoader)
  that don't override import_meta_resolve but do resolve JSR/npm specifiers.
- Update loader_resolve test to use the new register() API instead of the
  removed registerResolveMapping() function.

Node.js invokes registered loader hooks when import.meta.resolve() is
called (see test-esm-import-meta-resolve-hooks.mjs). Our current
implementation falls back to basic URL resolution for async hooks since
import.meta.resolve is synchronous. This test documents the expected
behavior and is ignored until a synchronous resolve mechanism (similar
to Node's resolveSync) is implemented.

The loader_resolve integration test hung because `op_loader_register()`
set a single `active` flag, causing the module loader to route ALL
operations (both resolve and load) through the JS hook bridge — even
when only a resolve hook was registered. Load requests went to a
dead-letter queue with no JS consumer, deadlocking the oneshot channel.

Fix: split `active` into `resolve_active` and `load_active` flags so
the loader only delegates to JS for hooks that were actually registered.

Also address dsherret's review: simplify the default `import_meta_resolve`
to just call `resolve_import` directly instead of calling `self.resolve()`
and silently falling back when it returns Async. Add explicit
`import_meta_resolve` override to `ExtModuleLoader` using its existing
`resolve_inner` method.

The existing default import_meta_resolve behavior (try self.resolve(),
fall back for Async) is intentional and documented with an ignored test.
A proper fix for async hooks in import.meta.resolve is planned via a
synchronous resolve mechanism.

Adds a Rust<->JS bridge that allows module.registerHooks() resolve and
load hooks to intercept ESM dynamic import() calls. Uses the same
async channel pattern as the checkin:loader test infrastructure:

- New ops: op_module_hooks_{register,poll_resolve,respond_resolve,
  poll_load,respond_load} bridge the CliModuleLoader to JS hooks
- LoaderHookRegistry (shared Rc between module loader and OpState)
  queues requests and routes responses via oneshot channels
- CliModuleLoader::resolve() returns ModuleResolveResponse::Async
  when hooks are active, allowing JS to intercept resolution
- CliModuleLoader::load() delegates to JS hooks before default loading
- Fallthrough: when hooks call nextResolve/nextLoad without
  intercepting, the response signals Rust to use default resolution
- prepare_load skipped when hooks active (virtual modules can't be
  fetched by the graph builder)

Resolve conflicts after feature/async-module-resolve landed in main.
Keep both CJS hook functions (executeResolveHookChain/executeLoadHookChain)
from main and ESM hook functions (executeEsmResolveHookChain/
executeEsmLoadHookChain) plus ESM loop infrastructure from this branch.

Previously, prepare_load was blanket-skipped for ALL dynamic imports
when module hooks were active. This meant non-intercepted dynamic
imports with non-static specifiers (not already in the module graph)
would fail with LoadUnpreparedModuleError.

Track which specifiers were actually intercepted by a resolve hook in
hook_intercepted_specifiers. Only skip prepare_load for those virtual
modules. Fallthrough-resolved specifiers still go through normal
prepare_load for graph building and permission checks.

Implements the Node.js module.register() API which loads hook modules
and registers their resolve/load hooks for ESM imports. This builds
on the existing registerHooks() infrastructure.

Key behaviors:
- Loads hook module via dynamic import()
- Calls initialize(data) with structured clone data and transferList
- Registers async resolve/load hooks into the ESM hook chain
- Supports LIFO chaining (last registered runs first)
- Sync hooks (registerHooks) run before async hooks (register) per spec
- Returns undefined immediately (hooks activate asynchronously)

Node compat test results: 5/48 async-loader tests pass, 20/62
module-hooks tests pass. Most failures are due to tests using
--experimental-loader flag or child process spawning patterns.

When CJS load hooks return format='module', loadESMFromCJS calls
op_import_sync which blocks the JS thread. If hooks are active, the
Rust module loader would push requests to the hook queue, but the
JS loop can't process them since the thread is blocked - deadlock.

Fix by:
- Skipping resolve hooks for already-resolved specifiers (file://,
  http://, etc.) since they don't need resolution and avoiding the
  async bridge prevents deadlocks from op_import_sync
- Skipping load hooks when is_synchronous is true (set by deno_core
  for op_import_sync paths)

Also add importAssertions (deprecated alias) to hook context objects
for Node.js compatibility.

Enable 30 node_compat tests that now pass:
- 25 test-module-hooks tests (registerHooks API)
- 5 test-async-loader-hooks tests (register API)

Previously only 10 were enabled.

Address review feedback:

1. Fix race between register() and subsequent imports: track pending
   hook module loads and await them in the ESM resolve loop before
   processing requests. Pre-activate resolve_active so imports are
   routed through the bridge and naturally wait for hooks to load.
   Remove all setTimeout workarounds from tests.

2. Stop swallowing hook module load errors: _loadAndRegisterHookModule
   no longer catches errors. Failures propagate as unhandled rejections
   and surface at the import site that triggered the hook bridge.

3. Only pre-activate resolve (not load) to avoid circular deadlock
   where the hook module's own load would go through the bridge that's
   waiting for the hook module to load.

…n compiled binaries

Enable the Node.js module customization hooks API in deno compile output.
This allows compiled binaries to register custom resolve/load hooks that
can intercept and transform dynamically imported modules at runtime.

Key changes:
- Wire up LoaderHookRegistry in StandaloneModuleLoaderFactory (was None)
- Add resolve hook bridge support in EmbeddedModuleLoader, routing
  external file:// imports through the bridge to ensure pending hook
  module loads complete before proceeding
- Add load hook bridge support for non-embedded files, allowing hooks
  to transform source (e.g., strip TypeScript types) before V8
- Add is_external_file_specifier() to distinguish embedded VFS files
  from external filesystem files
- Add load_inner() for hook fallthrough path

This enables use cases like bundling a TypeScript type-stripper into
a compiled binary and dynamically importing .ts files from disk at
runtime.