Description

Part of #7416. Stacked on #10115. This makes ScanStageCache::merge clean up dynamic import entry points when the dynamic imports behind them go away. Until now the entry list only ever grew.

Problem

Two related gaps in the entry point handling of merge:

1. Stale related_stmt_infos rows. The old code removed a re-scanned importer's rows only when the scan output contained a matching entry point, keyed by the incoming rows. When a re-scanned module removed its dynamic import entirely, the scan output had no entry for the target at all, so the importer's old rows stayed behind and kept pointing at statement and node ids of a module version that no longer exists.
2. Zombie entries. When the last dynamic importer of a module disappeared, the DynamicImport entry point stayed in the cache forever. Every incremental rebuild kept emitting a chunk for a module nothing imports dynamically anymore, which a fresh full build of the same files would not produce.

Fix

• Before merging the incoming entry points, drop the rows of every re-scanned module from the cached dynamic import entries. The incoming entries then re-add exactly the rows that still exist. This subsumes the old incoming-keyed extract_if, which is removed.
• After merging, prune every DynamicImport entry whose module no longer has any dynamic edge in the importers edge list. The edge list is reliable at merge time since fix(dev): update importer relationships of cached modules in incremental build #10107 and fix(dev): revert cache mutations when a partial scan fails #10110. Other entry kinds are untouched.
• The prune is intentionally not transitive on the cache: edges of orphaned importers survive in the edge list, so an entry only they point at stays cached, and re-adding an import of the orphan revives the entry without a re-scan. ScanStageCache::create_output compensates by filtering DynamicImport entries against module reachability (compute_live_modules, a BFS from the non dynamic entries), so only entries a live module dynamically imports produce chunks, matching a fresh build. This covers the transitive case: main imports hub, hub dynamically imports lazy, and dropping the hub import from main must also stop emitting the lazy chunk even though hub is never re-scanned.
• Partial scans no longer create a DynamicImport entry for a module that is a configured user entry. The scan local user_defined_entry_ids set is empty in partial mode, so the existing full scan filter never matched there, and a dynamic import of the entry module produced a second entry row (and a second chunk) for it.

Tests

• New fixture hmr/remove_transitive_dynamic_import_entry: main statically imports hub, hub dynamically imports lazy. Dropping the hub import from main removes the lazy chunk from the build output without re-scanning hub; re-adding it revives the chunk.
• New fixture hmr/remove_dynamic_import_entry: two modules dynamically import lazy.js and drop it one by one. After the first drop the entry survives through the remaining importer. After the second drop the lazy.js chunk disappears from the build output. Re-adding the import brings the entry and the chunk back.
• The state parity check from test(dev): assert incremental scan state matches a fresh full build after each HMR step #10115 is tightened for this: DynamicImport entries now must match a fresh full build exactly while a live module imports them; an entry kept in the cache only by orphans' dynamic import records is tolerated, since create_output filters it from the output and it exists precisely to make revival cheap (other kinds still allow extras on the incremental side until orphan cleanup lands). Reintroducing the bug locally makes the parity check fail on the new fixture with "dynamic import entry only exists in the incremental state", so the whole HMR suite now guards this behavior.

Docs

The entry point step of the merge algorithm in internal-docs/cache/implementation.md is updated.