Problem

First P1 item of #10294: ensure_runtime_module_for_order_wraps unconditionally evicts a co-hosted runtime module onto a standalone rolldown-runtime chunk (and mints one when the runtime was unplaced), even when every helper consumer lives in a single chunk. issues/9463 ships a rolldown-runtime.js whose only content is two helper re-exports consumed exclusively by common~a~b~shared.js — one extra request per page load for nothing, in both wrap modes.

The eviction itself is justified: the baseline merge proof (try_merge_runtime_chunk, called from generate_chunks and the chunk optimizer) runs before order analysis, so nothing it proved covers the helper demand order lowering adds (__esm/__esmMin per wrapper, __toCommonJS/__reExport per lowered overlay). What was missing is re-running the proof afterwards: by the end of lowering the full demand is materialized in OrderWrapState, so the complete post-lowering consumer set is knowable.

Fix

ensure_runtime_module_for_order_wraps keeps its normalize-to-standalone behavior unchanged, then re-runs the merge proof with the post-lowering consumer set:

• New OrderWrapState::runtime_helper_consumer_chunks collects the order-introduced consumers: each wrapper's synthetic init_* statement renders in its assigned chunk, and each overlay's lowered import/require glue renders in the importer's chunk. Pre-lowering demand is re-collected by collect_runtime_consumer_chunks's own scan (chunk helper bits, interop wrappers, statement-level runtime symbol references), and stale/tombstoned chunks are filtered by the existing post_chunk_optimization_operations guard.
• try_merge_runtime_chunk gains a RuntimeMergeCascade parameter. The two pre-existing call sites use Full (byte-identical cascade). The post-lowering fold uses SingleConsumerOnly, and two deliberate restrictions apply:
  • Sole-consumer hosts only. A dominator merge turns transitive reachability into a direct import whose exec-order sort position can hoist the host past sibling imports, and a bitset host can gain a brand-new consumer edge — either way the chunk-evaluation order deviates from what the on-demand analysis proved against the pre-fold edge set. A sole-consumer merge only removes that consumer's edge to an inert runtime-only chunk, so evaluation order is preserved by construction (this also makes the TLA/signature/cycle guards trivially satisfied, and keeps the existing sole-consumer allowance for manual group chunks).
  • Esm output only. Under cjs output, compute_cross_chunk_links later gives every ESM-exports entry chunk — including the zero-module order facades — a __toCommonJS demand that is invisible at fold time; folding would hand an entry chunk with no visible demand a brand-new require edge into a user chunk. Every other post-fold demand source was audited to be either Esm-excluded or already represented in the fold-time consumer set.
• In SingleConsumerOnly mode the merge tail skips target_chunk.bits.union(...): the sole consumer's own bits are already exact (the runtime becomes internal to it), while the order-time standalone chunk carries synthetic all-live-union bits whose widening would leak into bits-derived chunk names.

Non-esm formats and strictExecutionOrder: false builds are byte-for-byte untouched; the fold only runs from the order-wrap path (non-empty plan).

Output shape

issues/9463 (acceptance): rolldown-runtime.js disappears and the helpers inline into common~a~b~shared.js in both cells; same for issues/9463_plain_group, issues/9463_three_entries, and strict_execution_order/concatenate_basic (wrap-all cells fold into main2.js). 40 snapshots change, all strict-mode fixtures, all the same shape: the standalone runtime chunk is gone and its (actually demanded) helpers render inside the sole consumer — issues/5870 and mixed_static_dynamic_same_target also drop a previously exported-but-unconsumed __exportAll, since the host renders only demanded statements.

One snapshot-cosmetic note: in fixtures where the runtime region folds ahead of a synthetic wrapper rendered without its own region markers (pre-existing quirk), the HIDDEN [\0rolldown/runtime.js] replacement visually swallows the following wrapper in the snapshot (top_level_await_syntax). The raw emitted chunk was dumped and verified correct — init_foo is present; only the snapshot display collapses it.

Validation

• Full integration suite + workspace tests: failure list byte-identical to unmodified main (verified by stash-and-rerun on the same machine; the only local failures are the pre-existing css/legal-comments/esbuild-diff environment set).
• Execution-order fuzzer (rolldown-order-fuzzer) against this build, 300 cases across three cells: mixed 112/120, pure-ESM 83/100, wrap-all 71/80. The same three campaigns (same seeds and flags) were then run against an unmodified-main build of this worktree: the failing seed sets are identical and every one of the 34 failures carries a byte-identical verdict signature (the known Family-A / event-reorder arms tracked in strictExecutionOrder / onDemandWrapping: follow-up ledger #10294) — zero failure signatures introduced or altered by this change.

Part of #10294.