…ep (#10334)

## Summary

Flag-off builds could emit cross-chunk imports — and therefore run side effects — in a different order than `main`, on the default path. When the post-chunking runtime sweep drops the runtime module out of a shared chunk it co-hosts with user modules, that chunk was left with an execution order keyed on the removed runtime (exec order `0`) instead of its first surviving module, so it sorted ahead of chunks it should have followed. This restores `main`'s ordering by re-deriving chunk execution orders after the sweep.

## Verified mechanism

- Before #10104 (`1d86ffe06`), `sweep_unused_runtime_module` ran in `generate_chunks` **before** chunk exec-order assignment (there was a comment requiring it). #10104 moved the sweep into `finalize_chunk_plan`, which runs **after** assignment, so the regression is live on `main` today.
- The Common-chunk comparator keys on `modules[0]`'s exec order; `sort_chunk_modules` always makes the runtime (module exec order `0`) `modules[0]`. So a chunk hosting the runtime keys on `0`.
- When the walk-back (`find_entry_level_external_module`) invalidates the runtime demand (the #9374 star-re-export-to-external shape) and the sweep strips the runtime from a still-live shared chunk, the chunk keeps `exec_order` derived from the now-absent runtime. `rebuild_sorted_chunk_idx_vec(true)` only re-sorts the stale values; `renumber_live_chunks` is strict-only. That stale key feeds both `sorted_chunk_idx_vec` and the cross-chunk import sort (`compute_cross_chunk_links.rs:110/124`), so an entry emits `import "./C.js"` before a chunk that should run first.

## Fix

Chunk exec orders must already be assigned before order analysis runs (the on-demand actual-order simulation sorts sibling chunks by `exec_order`), so assignment cannot simply move after the sweep. Instead:

- Extract the assignment loop into `assign_chunk_exec_orders` (`code_splitting.rs`); keep the provisional call where it was in `generate_chunks`.
- Re-run it in `finalize_chunk_plan` when the sweep actually removed the runtime from a chunk — the same condition that already triggered `rebuild_sorted_chunk_idx_vec(true)` — then rebuild the sorted vec.

**Final ordering contract (documented on `assign_chunk_exec_orders`).** Flag-off, `analyze_execution_order` returns `None`, so no lowering and no `renumber_live_chunks` run; the re-run is the sole authority and reproduces exactly what `main` produced by sweeping before assignment. Under strict, the sweep block only runs when `required_runtime_helpers()` is empty (no order wrapper demands the runtime); `renumber_live_chunks` (strict-only, after lowering) merely *compacts* existing `exec_order` values to close tombstone gaps and never re-derives them from `modules[0]`. The re-run happens after lowering, so whichever of the two touches `exec_order` last leaves every live chunk both densely numbered and keyed on its correct lead module — they never contend.

## Behavior / snapshot impact

- **New fixture only.** `topics/runtime/sweep_shared_chunk_exec_order` — three entries; `re.js` (`export * from 'external'`) makes tree-shaking include the runtime for `__reExport`, and the runtime folds into `re.js`'s shared `{entry_a, entry_b}` chunk. The walk-back flattens the star re-export to a chunk-level `export * from "external"`, so the post-order sweep drops the runtime from that still-live shared chunk. `entry_a` also imports the earlier side-effect chunk `s_ac.js` (shared `{entry_a, entry_c}`).
- **Main-parity proof.** The fixture was built against three states. Pre-#10104 `main` (`ce98ae798`) emits `import "./s_ac.js"` before `import "./re.js"`; current `main` emits `import "./re.js"` first (the runtime-hosting chunk keeping stale exec order `0`) — a real side-effect-order change on the default path; this branch restores the pre-#10104 order. The committed snapshot is therefore the pre-regression output, not an expectation written to match the fix. Reverting only the two source files onto this branch reproduces the failure, so the fixture discriminates.
- **No existing snapshot changes.** No other fixture failed under `INSTA_UPDATE=no`, which is what a changed snapshot would do, so no existing snapshot changed.

## Validation

- `cargo test -p rolldown` — 1877 passed here against 1876 on `main`, the difference being exactly the new fixture. Both runs share the same 5 environmental failures (`cjs_module_lexer_compat` ×3 + `npm_packages/util_deprecate` need `pnpm install`; `test262_module_code` needs the submodule). Run with `INSTA_UPDATE=no`: `.insta.yaml` sets `update: 'always'`, so a local run without it rewrites snapshots in place and reports success regardless — worth knowing for anyone reproducing the revert-check above.
- `cargo fmt --all --check` — clean.
- `cargo clippy -p rolldown --all-targets -- -D warnings` — clean.

---

Follow-up to #10104; addresses item 3 of #10104 (comment)