WIP: Publish TS server plugin as standalone npm package

Overview

This issue collects work items for publishing the scratchpad TS server plugin (documentdb-scratchpad-ts-plugin) as a standalone npm package with its own release pipeline.

Currently, the plugin is bundled inline by webpack and requires a runtime node_modules stub created during extension activation (see ClustersExtension.ts). This workaround exists because:

• VS Code's typescriptServerPlugins resolves plugins via node_modules/<name> under the extension root
• @vscode/vsce hardcodes ignore: 'node_modules/**' in its file collection, so the stub cannot be shipped inside the VSIX
• The official VS Code docs recommend TS plugins be published as separate npm packages listed in dependencies

Steps (to be expanded)

• Publish documentdb-scratchpad-ts-plugin as an npm package (private or scoped)
• Add it as a production dependency in package.json
• Remove the runtime stub creation code from ClustersExtension.ts (marked with TODO)
• Remove the --no-dependencies flag from vsce package (or use packagedDependencies to include only the plugin)
• Remove the webpack entry point for scratchpadTsPlugin and the CopyWebpackPlugin stub entry (if still present)
• Verify the plugin loads correctly from the shipped VSIX in all environments

References

• Runtime stub code: src/documentdb/ClustersExtension.ts (search for TODO: Remove this runtime stub)
• Plugin source: src/documentdb/scratchpad/tsPlugin/index.ts
• VS Code docs: contributes.typescriptServerPlugins
• Vue/Volar uses the same runtime stub pattern: vuejs/language-tools

Start with src/documentdb/ClustersExtension.ts and search for TODO: Remove this runtime stub, then inspect src/documentdb/scratchpad/tsPlugin/index.ts and the package and webpack configuration. Verify how the plugin is packaged and loaded from the VSIX. Done means the standalone package is included as a production dependency, the runtime stub and obsolete webpack entries are removed, and the plugin loads in all environments.