[bartlomieju]

Adds a built-in synthetic_esm mechanism in libs/core so an
extension can map a module specifier (e.g. node:worker_threads) to
a backing polyfill script. On first import the loader evaluates the
script (once — the result is cached) and synthesizes an ES module
whose named exports are derived from Object.keys of the IIFE's
returned exports object, plus a default export pointing at the
object. This is Node's BuiltinModule.getESMFacade shape, but with
the mapping declared by extensions and the dispatch driven entirely
by libs/core, so it works for any extension that wants a
CJS-shaped polyfill exposed as ESM.

load_ext_script now caches its evaluated result so the
synthetic-esm dispatch and other callers (CJS require through the
JS-side loadExtScript wrapper) share one IIFE evaluation —
re-evaluating a polyfill body would clobber registered
internals.__* hooks and produce duplicate class identities. The
cache is snapshot-serialized via SnapshotDataId so the dispatch
can still find values evaluated at snapshot time.

node:worker_threads is the canary because it is the only
*_esm.ts wrapper today that needs live bindings — its
worker_threads_esm.ts used export let plus an
internals.__refreshWorkerThreadsWrapper callback to push
parentPort/threadId/workerData/isMainThread/resourceLimits
into the ESM facade after __initWorkerThreads. With this change the
wrapper is gone: the polyfill's tail IIFE returns a data-property
exports object, and __initWorkerThreads mutates those properties.
The synthetic module is constructed lazily on first import, after
bootstrap, so it snapshots the post-init values directly — no
refresh op required.

Stacked on #34035.

[fibibot]

node_compat::parallel::test-dns-resolver-max-timeout.js is a known flake (already marked flaky: true in tests/node_compat/config.jsonc), unrelated to this PR's worker_threads/core changes. Workflow still in progress; if it concludes failed, the job needs a re-run.

[fibibot]

The synthetic_esm dispatch is structured cleanly: add_synthetic_esm_module is the registry, build_synthetic_esm_module runs load_ext_script + new_synthetic_module_from_exports_object, and the three hook sites (resolve_callback, recursive_load's register_and_recurse + Loader::load sentinel, load_dynamic_import fast path) all gate on has_synthetic_esm_module. The loaded_script_results cache is the real load-bearing change — without it the static-ESM and CJS require paths would re-evaluate the IIFE and produce duplicate class identities / clobber internals.__* hooks, exactly as the commit body calls out.

worker_threads canary: dropping worker_threads_esm.ts plus the __refreshWorkerThreadsWrapper callback and swapping the getter-tail to a data-property exportsObj that __initWorkerThreads mutates is the right shape — first-import snapshots happen post-bootstrap so consumers see the resolved values. Existing tests already exercise this path (worker_threads_test.ts, tests/specs/node/worker_threads/*.mjs mix import *, named, and default imports), and CI is fully green across 100+ shards including the full wpt release linux-x86_64 run.

• nit: new_synthetic_module_from_exports_object does key_str.to_rust_string_lossy(scope) == \"default\" for every own property — a per-import UTF-8 conversion. key_val.strict_equals(default_str.into()) after creating default_str once would skip the alloc. Per-import cost so probably noise.
• nit: the per-property exports_obj.get(scope, key_val).unwrap() will panic if a future synthetic_esm target uses a throwing getter. Fine for worker_threads (data properties only), worth a doc-comment on new_synthetic_module_from_exports_object so future authors know.
• nit: no test directly exercises the "backing script did not return an object" error path — the macro shape makes that hard to misuse, so low priority.