fix: prevent duplicate VSIX installations by using package.json ident…

[rajj28]

What it does

Fixes #16845 - Prevents duplicate VSIX extension installations when the same extension is installed from VSIX files with different filenames.

Problem: Extensions installed via "Install from VSIX..." were identified by their filename rather than the actual extension identity from package.json. This allowed the same extension to be installed multiple times by simply renaming the VSIX file, resulting in:

• Multiple directories under deployedPlugins
• Only the first installed extension appearing in the IDE
• Contributions (commands) from later-installed VSIX files being silently ignored

Solution: Extract the true extension identity (publisher.name@version) from the VSIX's embedded extension/package.json instead of deriving it from the filename.

Changes:

• Added extractExtensionIdentityFromVsix() function in plugin-vscode-utils.ts that reads publisher, name, and version from the VSIX's package.json
• Modified LocalVSIXFilePluginDeployerResolver.resolveFromLocalPath() to:
  • Use package.json-based identity instead of filename for deployment directory naming
  • Check getDeployedPluginsById() to block duplicate installations of the same extension
  • Graceful fallback to filename-based ID if package.json cannot be read

How to test

1. Build a sample VSIX extension (e.g., Hello World sample)
2. Install it via Extensions: Install from VSIX...
3. Rename the VSIX file (e.g., hello-0.0.1.vsix → hello-renamed.vsix)
4. Attempt to install the renamed VSIX via Extensions: Install from VSIX...
5. Expected: Installation is blocked with a console message indicating the extension is already installed
6. Before fix: Both VSIX files would be installed, creating duplicate directories in deployedPlugins

Follow-ups

• Consider adding user-facing notification when duplicate installation is blocked (currently only logs to console)
• Potential enhancement: Allow version upgrades/downgrades via VSIX when different versions are detected

Breaking changes

• This PR introduces breaking changes and requires careful review. If yes, the breaking changes section in the changelog has been updated.

Attribution

Review checklist

• As an author, I have thoroughly tested my changes and carefully followed the review guidelines