fix(vite): keep each environment's outDir mapped to its own css-post plugin - #5330

Fixes #5329.

Since #5324, configResolved registers vite:css-post/vite:css for every environment's build.outDir. That's correct for a shared config build (builder.sharedConfigBuild: true, the #5323 scenario), where all environments share one resolved config and one set of css plugin instances.

But when a framework passes the plugin inline without sharedConfigBuild (as Astro does), Vite resolves a separate config per environment — each with its own vite:css-post instance — and calls configResolved on the same UnoCSS plugin instance once per environment. Each call overwrote every environment's outDir entry, so the last-resolved environment's css-post instance won for all keys. An environment's renderChunk then invoked a css-post handler bound to a foreign config whose buildStart never ran, crashing with Cannot read properties of undefined (reading 'get') in cssModulesCache.get(config).get(id) — the Astro output: 'server' build failure in #5329.

The fix keeps each resolved config's own build.outDir (and rollupOptions.output dirs) registration authoritative, while environment-derived dirs only fill gaps. Each environment's build now finds the css-post instance from its own config, whose module cache is seeded by that build's buildStart. Shared-config builds are unaffected: there is a single resolved config, so all dirs still map to its instance and the #5323 fixture still passes.

Added a fixture (test/fixtures/vite-environments-isolated) that mirrors the Astro setup — inline plugin, per-environment configs, client built first — which reproduces the exact Cannot read properties of undefined (reading 'get') crash before the fix. Also verified the original Astro repro from #5329 (output: 'server' + @astrojs/node + prerendered page) builds successfully with this patch and matches 66.10.0 behaviour.

PR created with the help of an agent.