<agent: daily-job rstack ecosystem-ci>

Ecosystem CI regression: rspack/examples and rsbuild/examples

Attribution: Confirmed downstream source

Impact: The unrelated rsbuild/tanstack-start example no longer compiles because Solid v1 consumers resolve against solid-js@2.0.0-rc.0 and cannot import ./web, ./store, or v1 exports.

Why this PR

Both the Rspack and Rsbuild ecosystem jobs fail with the same Solid export errors at this PR's downstream merge commit 2d1aa44, despite testing different selected upstreams. This PR adds the Solid v2 RC example and regenerates the shared lockfile; peer resolution then pulls Solid v2 into TanStack Solid helper packages used by the React TanStack Start example. The selected Rspack/Rsbuild commits are therefore surface attributions, not sources. This exposes a shared-workspace dependency isolation issue; the preferred fix owner is rstack-examples.

Suggested next step

Pin/isolate Solid v1 for the TanStack Start dependency graph while keeping the new Solid v2 example scoped to its own workspace; verify with pnpm --filter @rsbuild-example/tanstack-start build, then pnpm test --stack rspack examples and pnpm test --stack rsbuild examples. A fallback is to temporarily revert or exclude the Solid v2 workspace from the shared lockfile graph.

• Current runs: https://github.com/rstackjs/rstack-ecosystem-ci/actions/runs/32224957159 and https://github.com/rstackjs/rstack-ecosystem-ci/actions/runs/32221872047
• Tested upstreams: rspack at 77f4caa4f6972bbfc2b1fc8009d34abca225bb8f; rsbuild at 01b5decdd995e73774834579bc501c1a02783bbe
• First bad / previous good: downstream 2d1aa44 versus ed94416 in the earlier green examples jobs; PR feat: upgrade Rsbuild Solid example to v2 RC #495 is the dependency-changing commit in that interval
• Failure signature: package subpaths ./web and ./store are not exported, plus missing Solid v1 exports such as onMount
• Flaky/pre-existing check: the same deterministic compiler errors occur in both ecosystems; the earlier downstream ref passed
• Config check: not applicable; the failure comes from the regenerated shared dependency graph
• Alternatives ruled out: different selected upstreams produce the identical error at the same downstream SHA, and the changed dependencies/lockfile directly explain the resolution