fix(plugin-vue): isolate ssr and client descriptor state (fix #764)

[seanogdev]

Description

Fixes the descriptor-cache poisoning described in #764.

packages/plugin-vue/src/utils/descriptorCache.ts keys its descriptor cache by filename only, and vue/compiler-sfc's parseCache returns the same SFCDescriptor object for the same source. compileScript mutates that descriptor with ssr-specific compiled state, so an ssr transform followed by a client transform of the same SFC produces a <script setup> whose __returned__ omits template-only imports. The rendered component then throws $setup.<Component> is not a function.

This PR:

1. Keys the plugin's descriptor caches (cache, hmrCache) by (filename, ssr) via a composite string key. ssr is threaded through createDescriptor, getDescriptor, invalidateDescriptor, and the load/transform sub-block handlers (which already had ssr in scope from opt.ssr). prevCache (HMR diffing) stays filename-keyed because HMR is client-only.
2. Clones the descriptor returned from compiler.parse (shallow spread plus shallow clones of script, scriptSetup, template, styles, customBlocks). Step (1) alone is insufficient because parseCache returns the same descriptor for the same source regardless of our cache key — the clone gives each cache entry an object compileScript can safely mutate.
3. Updates invalidateScript and handleHotUpdate to invalidate both ssr/client entries (new peekCachedDescriptor / setCachedDescriptor helpers).
4. Leaves ?src= descriptors (setSrcDescriptor / getSrcDescriptor) filename-keyed — they're only consumed by the style transform, never by compileScript.

Adds a regression test __tests__/ssr-then-client-cache.spec.ts that:

• Simulates the ssr-then-client flow via transformMain + resolveScript
• Fails without the descriptor clone (verified locally by stripping just the clone and re-running)
• Passes with the full fix

Additional context

Symptom was first reported as vitest-dev/vitest#9855 because Vitest's related command surfaces it via cross-project SSR dependency analysis, but the bug is plugin-vue's — any ssr→client transform order on the same SFC reproduces it.

Verified downstream by re-running the teamwork.com monorepo's pnpm test related $files (the command that was failing on our branch) against a linked build of this branch: 3 previously-failing storybook tests now pass, 120/120 total — with no changes to the consuming component (the <script setup> const workaround was reverted before the run).

---

What is the purpose of this pull request?

• Bug fix
• New Feature
• Documentation update
• Other

Before submitting the PR, please make sure you do the following

• Read the Contributing Guidelines.
• Read the Pull Request Guidelines and follow the PR Title Convention.
• Check that there isn't already a PR that solves the problem the same way to avoid creating a duplicate.
• Provide a description in this PR that addresses what the PR is solving, or reference the issue that it solves (e.g. fixes #764).
• Ideally, include relevant tests that fail without this PR but pass with it.