Implements sub-step 4 of the document-level ES module work: dynamic `import(specifier)` now evaluates to a Promise for the target module's namespace object, resolved off the same loader that handles static imports. Engine (crates/js): - Parser routes `import(...)` (but not `import.meta`) to a new `__we_dynamic_import` runtime helper. - New `dynamic_import` module: the helper resolves the specifier against the document base URL, returns a pending promise, and queues it; the event loop (`pump`/`run_event_loop`) drains the queue, settling each promise from the shared `__we_modules` registry (resolve with the namespace when present, otherwise reject with a "failed to fetch dynamically imported module" reason). Pending promises are GC-rooted. - `module::dynamic_import_specifiers` best-effort-collects string-literal `import("<literal>")` specifiers from a program. Loader (crates/browser): - The module graph builder eagerly fetches and executes statically-discoverable dynamic-import targets as ordinary dependencies so the runtime import resolves from the populated registry. Tests: - Unit tests for promise resolution, the returned promise shape, rejection of unloaded modules, and literal specifier discovery. - e2e page + scenario (`dynamic_import.we`) loading a `data:` module via `import()` and asserting the resolved namespace's constant and a callable export render into the DOM. Known follow-ups (still tracked under #304/#280): import-map bare specifiers, module-relative (vs document-base) specifier resolution, classic-script dynamic-import preloading, and lazy (non-eager) fetching of runtime-computed specifiers. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>