#8989) (#9057)

Fixes #8989, a circular import that arises when facade chunk elimination adds new runtime-helper consumers (`__exportAll`, `__toESM`, etc.) to a chunk that already has a transitive forward path back to the chunk currently hosting the runtime module.

### Root cause

`optimize_facade_entry_chunks` runs after the merge phase has already placed the runtime module into some chunk based on bitset assignment. When facade elimination later calls `include_symbol(namespace_object_ref)` for an eliminated facade, it sets `target_chunk.depended_runtime_helper.insert(ExportAll)` and adds the target to `runtime_dependent_chunks`. If the target chunk transitively reaches the chunk currently hosting the runtime, the new helper-import edge closes a cycle.

For example, in the regression test the merge phase puts runtime in `chunk(node2)` which has a forward path `node2 -> node3 -> node4`, and facade elimination then makes `chunk(node4)` need `__exportAll` from `chunk(node2)` — closing `entry2 -> entry3 -> node4 -> entry2`.

### Algorithm

The fix replaces the original "place runtime once and never move it" branch in `optimize_facade_entry_chunks` with a two-step decision that runs whenever `runtime_dependent_chunks` is non-empty (i.e., facade elimination has actually added new consumers).

**Step 1 — Peel decision (cycle prevention):**

The runtime is peeled out of its current host chunk only when both predicates hold:

- `host_has_other_modules` — the host chunk contains modules besides the runtime. If runtime is alone in its chunk, that chunk is already a leaf with no outgoing imports and cannot participate in a cycle. Skipping this case avoids leaving an empty chunk that would crash downstream code expecting `chunk.modules[0]` to exist.

- `has_external_consumer` — `runtime_dependent_chunks` contains a chunk that is *not* the host. If every facade-elim consumer IS the host itself, then helpers don't have to cross any chunk boundary and no new edges are introduced.

When both are true, the implementation removes `runtime_module_idx` from the host chunk's `modules` vec via `swap_remove` (ordering doesn't matter — `sort_chunk_modules` re-establishes it later) and clears `module_to_chunk[runtime_module_idx]`.

**Step 2 — Placement decision (consumer-set count):**

When the runtime is unplaced (either because Step 1 just peeled it, or because the merge phase never placed it), the implementation computes the full set of consumer chunks as:

```
consumer_chunks = (non-removed chunks with non-empty depended_runtime_helper) ∪ runtime_dependent_chunks
```

The first term picks up chunks that already required helpers from the linking stage; the second term picks up chunks that facade elimination just announced. Deduplication is automatic via `FxHashSet`. Then:

- `consumer_chunks.len() == 1` → runtime moves into that single consumer chunk. No extra chunk is created; the lone consumer hosts both its own modules and the runtime.
- `consumer_chunks.len() > 1` → runtime is placed in a fresh `rolldown-runtime.js` leaf chunk created with the runtime's bitset. Every consumer imports from it; the dedicated chunk has zero outgoing edges so cycles are structurally impossible.

### Why both steps are needed

The peel gate exists because relying on the consumer-count alone over-triggers — many tests have multiple consumers that don't actually form cycles (e.g., `import_missing_neither_es6_nor_common_js`, where runtime lives in `foo.js` and `require.js` imports `__toCommonJS` from it without any back-edge). The peel gate keeps these untouched.

The consumer-set count exists because relying on `runtime_dependent_chunks.len()` alone (the original code's optimization) undercounts: it ignores chunks that already required helpers from the linking stage. After peeling, the unioned set correctly identifies whether runtime can piggyback on a single consumer or needs its own home.

### Test results and snapshot impact

Net change against `main`: only `chunk_optimizer.rs` and a new regression fixture at `crates/rolldown/tests/rolldown/issues/8989/`. **Zero existing snapshots are modified.** All 1677 integration tests pass.

The 8989 fixture covers the cycle: 4 entries (`node0`–`node3`), `node4` dynamically imported from `node3`, `node1` namespace-importing `node2` (forcing `__exportAll` for `node2`'s namespace materialization). The output places runtime into `node4.js` (the leaf), which both `entry2` and `entry3` reach through forward-only edges. Acyclic ✓.