fix: keep dynamic entry as the facade of its codeSplitting group chunk - #11507

…ntry module

A `codeSplitting` group with `includeDependenciesRecursively: false` can take an entry module and leave its dependencies in the entry chunk, which then imports the group chunk. Keyed on those dependencies, the entry chunk sorted before the group chunk in the imports of other chunks, and when the two chunks import each other the group chunk's modules ran before those dependencies. An entry chunk whose entry module is in another chunk keys on its entry module.

…just the entry's exports

When a `codeSplitting` group that captures a dynamic entry moves into the entry chunk, every binding that other chunks import from the group becomes an export of the entry chunk, and `import()` of the entry gives it as an extra key. As Rollup's `canModuleBeFacade` does, fold the group only when every binding that other chunks import from it is an export of the entry module; otherwise keep the facade-elimination path and its simulated namespace. `bindings_imported_from_other_chunks` predicts these bindings from the imports of the modules instead of running the cross-chunk link pass.

The folded chunk also takes over the group's `chunk_reason_type`, so the runtime placement does not make it the runtime host for other consumers, as it does not choose the group chunk. The helpers that those consumers import would otherwise be keys of the namespace.

`issue_5276_2`, `dynamic_import_host_exporting_then` and `dynamic_import_host_exporting_aliased_then` use their original inputs again, and their output is the same as on main. `facade_elimination_with_shared_cjs_dep` uses its original input too: `en_US` folds, and `ar_EG`, whose group holds a CommonJS module that `en_US` also imports, keeps the simulated namespace.