…try's module (#9997)

## Summary

Fixes the `strictExecutionOrder` execution-order corruption reported in #9463: with `experimental.chunkOptimization` and a `codeSplitting` group that captures multiple **user-defined entry** modules, executing one entry eagerly ran another entry's top-level side effects.

Reproduction (the issue's REPL, as `tests/rolldown/issues/9463/`): entry `a` statically imports `shared`, entry `b` dynamically imports it, with an `entriesAware` group + large `entriesAwareMergeThreshold` + `strictExecutionOrder`.

Before — loading `b` runs `a`'s side effects:
```js
// a.js  → init_a/init_b/init_shared live here; chunk top-level unconditionally calls:
init_a();
export { init_b as t };
// b.js
import { t as init_b } from "./a.js";   // importing a.js runs init_a() first
init_b();
```
After — each entry runs only its own `init_*`:
```js
// a.js → import { n as init_a } from "./common~a~b~shared.js"; init_a();
// b.js → import { t as init_b } from "./common~a~b~shared.js"; init_b();
```

## Root cause

Manual code splitting can place several user-defined entry modules into one shared `Common` chunk (the `entriesAware` `entriesAwareMergeThreshold` merges subgroups by bitset similarity and unions their bits; a plain group unions bits directly). `chunkOptimization`'s facade elimination (`find_facade_chunk_merge_ops`) then folds that shared chunk **into** one entry chunk, which makes that entry chunk eagerly run its own `init_*`. The other entry, whose module also lives in the shared chunk, is then forced to `import` the first entry chunk to reach its own module — and running that chunk eagerly executes the first entry's side effects.

The existing safety check only ran for `preserveEntrySignatures: 'strict'`. Entries with no exports resolve to `AllowExtension` and took the `_ => true` arm, so nothing blocked the fold.

## The fix

In the user-defined-entry branch of `find_facade_chunk_merge_ops`, only fold the common chunk into the entry chunk when that chunk does **not** also hold another user-defined entry's module. Otherwise the thin facade is kept, so each entry imports the (wrapped) shared chunk and runs only its own `init_*`.

A common chunk that holds just this entry's module (plus non-entry deps a sibling genuinely depends on) is still folded — preserving the #5726 facade elimination.

## Tests

Three fixtures with **behavioral** `_test.mjs` that execute the output and assert the actual semantics (not just chunk snapshots) — each module records its top-level side effect in a global; loading entry `b` must run only `b`'s side effects and must not contain another entry's:
- `tests/rolldown/issues/9463/` — the reported case (entriesAware group, dynamic shared dep).
- `tests/rolldown/issues/9463_plain_group/` — plain (non-`entriesAware`) group, to prove the guard is not entriesAware-specific.
- `tests/rolldown/issues/9463_three_entries/` — three entries, to prove it scales past two.

All three were confirmed to **fail on the pre-fix code** (e.g. `["a","shared-foo","b","shared-foo"]`) and pass with the fix.

I also audited the rest of the chunk-optimizer merge/fold/wrap sites for the same "eager cross-entry execution" family and verified (by running probes) that the **strict** path is otherwise closed: under `strictExecutionOrder` every side-effectful module is wrapped (including under `onDemandWrapping`, since an observable side effect makes a module execution-order-sensitive), so the only eager leak was the entry-chunk fold fixed here. Dynamic→group / dynamic→common / dynamic→user-entry / static-via-intermediate / plain-group shapes were all checked and are isolated under strict. Full `rolldown` integration suite: no snapshot regressions; `#5726` and `strict_execution_order/on_demand_wrapping` unchanged.

## Out of scope / follow-up

This addresses the `strictExecutionOrder` case from the issue. The same logical leak still exists **without** `strictExecutionOrder` when a manual code-splitting group co-locates modules of different entry reachability: there the shared chunk's modules are eager (unwrapped), so loading one entry runs the co-located code of another. For non-entry modules this is the pre-existing manual-group over-inclusion tradeoff (see `advanced_chunks/entries_aware_merge_shared_deps`); for entry modules it is a genuine isolation gap. The structural cause is manual code splitting producing chunks whose `bits` is a union across modules of different reachability. Tracked in #9998; a complete fix would make manual splitting respect reachability boundaries (or keep cross-entry modules wrapped in non-strict mode too).

Closes #9463