Community add-on caching bugs

[sacrosanctic]

describe the issue

cli/packages/sv/src/core/fetch-packages.ts

Line 14 in 03fc69b

const NODE_MODULES = fileURLToPath(new URL('../../node_modules', import.meta.url));

This constant is only correct for sv's dev-checkout layout (src/core/… → packages/sv/node_modules).
In the published bundle the chunk lives at sv/dist/engine-*.mjs, which produces three problems:

1. Doubled node_modules path.
   …/node_modules/sv/dist/../../node_modules resolves to …/node_modules/node_modules.
2. Global pnpm store pollution.
   With pnpm dlx sv, sv's install dir is inside the content
   store (~/.local/share/pnpm/store/v11/links/@/sv/<version>/<hash>/), which is meant to be
   immutable, content-addressed, and state-free. Every community add-on download writes mutable
   state (node_modules/node_modules/<addon>/, extracted tarballs and symlinks) into the store:
   • shared across all projects and never invalidated (not on sv upgrade, not by pnpm store prune);
   • concurrent sv runs race on the same paths (one run's rmSync deletes what another extracts).
3. Stale symlink
   It's not cleaned up due to the fork in the control flow

Reproduction

# 1. add a local add-on by path — creates <cache>/node_modules/node_modules/<name> symlink
pnpm dlx sv create ./a --template minimal --types ts --no-install --no-download-check --add file:/path/to/my-addon
# 2. add the same package name from npm — extract collides with the symlink
pnpm dlx sv create ./b --template minimal --types ts --no-install --no-download-check --add my-addon
# => "Failed to resolve my-addon … /node_modules/node_modules/my-addon is not a valid path"

# observe store pollution:
ls "$(pnpm store path)"/links/@/sv/*/*/node_modules/node_modules