[vite-plugin] Vitest fails at startup since 1.58.0: "There is already a server associated with the config."

Finding: In an external report, running `vitest run` (vitest 5.0.2, vite 8.3.1, wrangler 4.144.0, Node 24.18.0, pnpm 12.6.0, macOS arm64) in a project whose Vite config includes `cloudflare()` from @cloudflare/vite-plugin fails at startup with "There is already a server associated with the config." on plugin 1.58.0 and 1.62.2, while 1.57.3 passes (https://github.com/cloudflare/workers-sdk/issues/15969). The reporter also says that removing `cloudflare()` from plugins on 1.62.2 makes the test pass, and that a jsdom test environment makes no difference. Reported evidence: the reporter supplies a five-file minimal reproduction and a stack trace running from Vite `_createServer` through Vitest `createViteServer`, `createClusterServer` and `attachProjectsFromEntries` (https://github.com/cloudflare/workers-sdk/issues/15969). An automated triage comment, itself an LLM-generated summary that may contain errors, states it reproduced the failure once on the pinned versions and that 1.57.3 passed in a baseline run (https://github.com/cloudflare/workers-sdk/issues/15969#issuecomment-5912340795). It labels the issue a regression. This is external-report and automated-triage evidence only, not an independent human reproduction. Hypothesis, not confirmed: the reporter, reading the 1.62.2 dist, attributes the failure to the container cleanup added in 1.58.0 (#15765). They say `getDevContainerCleanup` replaces `server.config` with a copy, Vitest 5 matches projects to servers by config object identity, the lookup misses, and Vitest calls `createServer()` again, which trips Vite's guard against reusing a config (https://github.com/cloudflare/workers-sdk/issues/15969). No maintainer has confirmed this in the supplied data. The proposed fix, a module-level WeakMap or in-place mutation, is a suggestion only. Status: the issue is open. No fix commit or released fix appears in the supplied sources. Limitations: this is one issue, on one OS and package manager, with possibly omitted middle comments. KFA did not reproduce it. Practical options reported are pinning to 1.57.3 or excluding the plugin from the test config; the reporter's table shows both passing, but neither is verified by KFA and dropping the plugin may change test behavior.