`fsModuleCache` cannot be shared between checkouts: keys hash absolute module ids and the absolute root

Clear and concise description of the problem

In 5.0.0 the file-system module cache cannot be shared between checkouts. cacheKey = sha1(id + fileContent + environmentHash + coverageAffectsCache) where id is an absolute module path and environmentHash includes root: config.root (dist/chunks/index.B89dZ0-N.js:6740-6770). Entry bodies embed /@fs/<absolute path> specifiers, and the //# vitestCache= footer carries base64 JSON holding the absolute id, url and deps (:6640-6652), so even a deliberate relocation pass cannot work by text substitution. A cache warmed on CI is therefore a complete miss in a developer checkout, and under pnpm's global virtual store even two checkouts on one machine differ. In our monorepo the cache is 25 MB of pure weight in any shared cache artifact.

Suggested solution

Key module ids relative to the project root: store them relative to fsModuleCachePath and re-expand on read. root could then leave the environment hash, since the cache location already implies it. fsModuleCachePath already lets the cache be placed and its partition content-addressed by the lockfile, so the key is the only obstacle left.

Alternative

None that works from outside: renaming every file and rewriting every footer would require recomputing an environment hash only Vitest can compute.

Additional context

#10701 stabilized the feature without discussing portability.

Validations

• Follow our Code of Conduct
• Read the Contributing Guidelines
• Read the docs
• Check that there isn't already an issue that requests the same feature to avoid creating a duplicate

Start at the fsModuleCache logic referenced in dist/chunks/index.B89dZ0-N.js:6640-6770, focusing on cache-key generation, fsModuleCachePath, and the vitestCache footer. Trace how module ids and root enter the key and serialized data; done means a cache warmed in one checkout can be read from another checkout without rewriting absolute paths.