fix(bundled-dev): bind environment in hotUpdate plugin hook

[santhiprakash]

Summary

• Wrap the Vite-specific hotUpdate hook in injectEnvironmentToHooks, matching how resolveId / load / transform and Rollup hooks get this.environment.
• Add a unit test that asserts this.environment.name is available inside wrapped hotUpdate.

Fixes #23314.

Context

Under experimental.bundledDev, plugins are cloned through injectEnvironmentToHooks before being passed to the rolldown dev engine. That helper only wrapped hooks listed in ROLLUP_HOOKS (plus the three special-cased transform hooks). hotUpdate is Vite-specific and was skipped, so plugins following the documented Environment API (e.g. @tanstack/start-plugin-core reading this.environment.name) threw on every edit and left stale output until restart.

This is intentionally narrow: it only fixes the missing this.environment binding. It does not overlap with #22956, which adds the broader bundled-dev hotUpdate adapter.

Test plan

• Added injectEnvironmentToHooks unit test in packages/vite/src/node/__tests__/build.spec.ts
• CI test-unit (local run blocked by missing vite build artifact in this environment; upstream CI should cover)

[santhiprakash]

Rebased onto current main (dd1a8fbea) to resolve a conflict in packages/vite/src/node/__tests__/build.spec.ts introduced by #23311 (ci: set up bot workflow and ai policy).

The conflict was mechanical: #23311 added buildProjectWithRenderBuiltUrl as a free function, and this PR placed the new describe('injectEnvironmentToHooks') block immediately after the previous sibling test. The rebase keeps both: buildProjectWithRenderBuiltUrl is preserved at its new location, and the new describe block sits after it. No source changes in packages/vite/src/node/build.ts.

mergeable_state is now blocked (was dirty before) — only waiting on CI.

[santhiprakash]

Rebased onto current main (a98c8d95d) to clear the merge conflict — only conflict was in packages/vite/src/node/__tests__/build.spec.ts import block (upstream mainline had already added injectEnvironmentToHooks to the '../build' named imports and reordered the BuildEnvironment, resolveConfig line alphabetically; my commit's getHookHandler/Plugin additions survived, only the duplicate BuildEnvironment, resolveConfig line got dropped). packages/vite/src/node/build.ts (the hotUpdate-outside-switch rewrite) auto-merged cleanly. New head: ad34a22c. CI rerun in progress.

[santhiprakash]

Differential repro for lightningcss > async css order with css modules

I re-ran the playground/css/__tests__ serve suite locally against the base a98c8d95 and PR head fc9227de with packages/vite freshly built in each worktree.

Environment

• Node 20.20.2
• pnpm 10.34.5
• Command: pnpm vitest run -c vitest.config.e2e.ts playground/css/__tests__
• Built packages/vite before each run

Results (full suite, 5 runs each)

SHA	branch	fails / 5	observed failure
a98c8d95	base / main	4/5	async css order with css modules expected pink, got black
fc9227de	PR head	1/5	same assertion

The assertion also reproduces on base in isolation (playground/css/__tests__/lightningcss/lightningcss.spec.ts).

Conclusion

This is not a head-only regression. The same black vs pink failure is flaky on a98c8d95 itself. The PR branch may shift the failure rate, but the underlying CSS order instability is inherited from the current base / main. The upstream a98c8d95 CI is already red on the same async css order with css modules assertion on Node 24 (check run 96999011597), so this appears to be the same inherited flake rather than something introduced by the hotUpdate environment binding change.

No source change is being made for this issue; I’m treating it as inherited-from-main and leaving the PR branch as-is.

(Not chasing #23324 / #23320 / #23268 per the task scope.)

[github-actions]

The PR has been manually labeled as likely to be created by a bot, LLM, or agent, and will be automatically closed. This may be because the PR contains LLM-generated descriptions, does not follow the PR template, is overly verbose, or does not contain any fruitful interaction, which harms the review process. Please read our AI policy for more information.

If you believe this is a mistake, please reply to this comment and we will review it.