fix(rsc): resolve facade client entry with strictExecutionOrder

[james-elicx]

Description

With output.strictExecutionOrder: true on the client environment, which codeSplitting.experimentalInlineCommonChunks also turns on by default, every build with at least one client component fails:

[vite-rsc] Client build must have an entry chunk named "index". Use 'customClientEntry' option to disable this requirement.

Rolldown keeps the browser entry's modules out of the index chunk when they're shared with client reference chunks (React alone is enough). index becomes an empty facade that only imports and runs the shared chunk, e.g. import{t as e}from"./entry.browser-….js";e();. The assets-manifest hook finds the entry through collectAssetDeps, which maps module id to chunk. The facade has no moduleIds, so it's never found.

The fix looks up the index entry chunk directly in the bundle and walks its deps with collectAssetDepsInner. For non-facade entries the result is the same as before. For a facade entry, clientEntryDeps now starts at the facade and includes the shared chunk it imports, so modulepreload still covers the entry's code.

I checked the other module-id lookups in this hook. Client reference groups are their own dynamic entries and keep their modules, so they're unaffected.

Tests

New strict-execution-order e2e block in e2e/starter.test.ts: an inline examples/starter fixture with strictExecutionOrder: true on the client environment. It's skipped on Rollup-based Vite (the vite-7 job) the same way e2e/rolldown.test.ts is, since Rollup has no strictExecutionOrder.

• Runs the full defineStarterTest suite in build mode: hydration, client component, server action with and without JS, CSS, and assets.
• Checks that the fixture really emits an empty-facade index entry (no moduleIds, at least one import). The fixture records the chunk shape from generateBundle. If a future rolldown stops producing this shape, the test fails instead of silently passing.
• Checks that clientEntryUrl points at the facade and that clientEntryDeps.js includes the facade and the chunks it imports.

It lives in starter.test.ts rather than its own spec file on purpose. As a separate file it ran on the other worker and could copy examples/starter while dev-default > client hmr had it mid-edit, building a fixture with Client [edit] Counter.

The commits are split to show red then green:

• test(rsc): … adds only the test. The fixture build fails with the error above.
• fix(rsc): … makes the test pass: 8 passed, 3 HMR cases skipped in build mode.

e2e/client-entry-url.test.ts still passes.

E2E race fixes

CI on this PR kept failing on existing dev tests that are also flaky on main nightlies, so I tracked two of them down (last commit):

• useCreateEditor writes are spaced at least 100ms apart per file. Vite's chokidar watcher drops a change event that arrives within 50ms of the previous one for the same path. When the HMR round trip is fast, editor.reset() lands inside that window and Vite never sees it. A CI trace of dev-no-ssr > client hmr showed the reset written about 55ms after the edit, with only one hot updated message. All three attempts got stuck on Client [edit] Counter: 1. A standalone probe against Vite's watcher reproduces the drop with a 20ms gap.
• use-cache-persistent waits for the rsc:update refetch before page.reload(). Previously the reload could abort the in-flight _.rsc GET, which WebKit reports as an unhandled TypeError: Load failed. The late update could also reach the reloaded page before its effect assigned setPayload, giving setPayload is not a function. Delaying that GET by 300ms reproduces the WebKit failure locally; with the change it passes.
• setupIsolatedFixture gets 60s instead of the default 30s hook timeout. It runs pnpm i over the network, which took 16-34s on macOS runners. The react-server-dom-webpack fixture installs twice, so its beforeAll regularly timed out, including on main nightlies.

Context

Found while trying rolldown's codeSplitting.experimentalInlineCommonChunks (rolldown/rolldown#11040) in an RSC framework (vinext). The repo's rolldown 1.2.9 reproduces it with strictExecutionOrder alone, so the test doesn't need the experimental option.

[hyfdev]

I'm checking if it's possible to support inlineCommonChunks with preserveEntryExportSignature

[hi-ogawa]

Fix looks good! Thanks for e2e fix too. I'm splitting changes for e2e to just sort out some polish.