Add extension contract tests

[zackverham]

Summary

• Adds test/extension-contract-tests/ — a contract test suite that validates which VSCode and Positron APIs the extension calls, with what arguments, and what it expects back
• Tests mock the vscode and positron modules, import actual extension source code against those mocks, and assert API interactions
• Includes compile-time conformance checks (tsc) that verify mock properties exist in the real @types/vscode and Positron type definitions
• No Go binary, no HTTP server, no network — tests run entirely in-process using Vitest with module aliasing
• Adds just test-extension-contracts and just check-extension-contract-conformance recipes
• Adds extension-contract-tests workflow to CI (pull request, main, nightly)

What's tested

Test File	Extension Source	APIs Validated
activation	extension.ts	activate() wiring: trust, URI handler, commands, contexts
auth-provider	authProvider.ts	authentication.registerAuthenticationProvider
connect-filesystem	connect_content_fs.ts	workspace.registerFileSystemProvider, FileSystemError
dialogs	dialogs.ts	window.showInformationMessage (modal), l10n.t
document-tracker	entrypointTracker.ts	Editor/document change events, commands.executeCommand("setContext")
extension-settings	extension.ts	workspace.getConfiguration("positPublisher")
file-watchers	watchers.ts	workspace.createFileSystemWatcher, RelativePattern
interpreter-discovery	utils/vscode.ts	commands.executeCommand, workspace.getConfiguration, Positron runtime
llm-tools	llm/index.ts	lm.registerTool
open-connect	open_connect.ts	window.showInputBox, workspace.updateWorkspaceFolders
positron-settings	utils/positronSettings.ts	workspace.getConfiguration("positron.r")
window-utils	utils/window.ts	window.showErrorMessage, withProgress, createTerminal

Test plan

• just test-extension-contracts passes
• just check-extension-contract-conformance passes
• CI extension-contract-tests workflow passes

🤖 Generated with Claude Code

[dotNomad]

Overall this idea is great. I had a couple ideas that I think are worth digging into a bit to simplify

---

I wonder if we can simplify this a bit by using a __mocks__ folder

If there is a mocks folder alongside a file that you are mocking, and the factory is not provided, Vitest will try to find a file with the same name in the mocks subfolder and use it as an actual module. If you are mocking a dependency, Vitest will try to find a mocks folder in the root of the project (default is process.cwd()). You can tell Vitest where the dependencies are located through the deps.moduleDirectories config option.

There is an example of __mocks__ in the File System example: https://vitest.dev/guide/mocking/file-system.html#example

[dotNomad]

Could bump up to the latest vitest here.

[dotNomad]

Do we use this tsconfig.json at all? I only see the conformance one being used in the package.json

[dotNomad]

For these enum should we just import them from vscode? I can't see a reason for us to duplicate them here.

[zackverham]

According to claude, we shouldn't / can't do this:

No, you shouldn't import enums from vscode directly in the mock file. Here's why:

  The vscode module is not a real npm package — it's a virtual module provided by the VS Code runtime at extension load time. In Vitest (which runs outside VS Code), there is no real vscode module to import
  from. That's exactly why every test file uses vi.mock("vscode", () => { ... }) to provide a fake implementation.