fix(vscode): stop the LSP restarting on unrelated configuration changes

[tripleaceme]

Description

Fixes #5920. Fixes #5642.

Both issues are the same bug: the extension restarted the language server far more often than it needed to, and let those restarts overlap. That produced the errors reported in both — Client got disposed and can't be restarted, and a stream of command 'sqlmesh.external_model_update_columns' already exists.

1. The LSP restarted on every configuration change in the editor

extension.ts subscribed to workspace.onDidChangeConfiguration and restarted unconditionally:

onDidChangeConfiguration(() => restartLsp()),

That event fires for any setting in the editor, including settings written by other extensions. It now restarts only when a section the server actually reads is affected — sqlmesh (which covers projectPaths and lspEntrypoint, both of which decide how the server is launched) or python.defaultInterpreterPath (the server runs inside that interpreter).

This accounts for the observations in #5642 that were otherwise hard to explain:

• Running any python command in a VS Code terminal killed the extension — the Python extension touches its own settings in response, and that alone triggered a restart.
• Running a copy of the same interpreter from a different path did not reproduce it — an unrecognised path makes the Python extension do nothing.
• su, uvx, a subshell or a notebook did not reproduce it either — none of those go through VS Code's shell integration, so no setting is written.

2. Restarts could overlap

LSPClient.restart() is stop() then start(). With a burst of triggers, several of those interleave: the outgoing client's command registrations collide with the incoming client's, and in-flight requests are aimed at a client that has already been disposed — exactly the two error messages in the reports.

Restarts are now serialized. Triggers arriving mid-restart collapse into a single rerun rather than queueing one restart each, since all a trigger needs is for a restart to have happened after it. An explicit restart (sqlmesh.restart, sign-in, format) is never downgraded to an automatic one when coalesced with one.

A related finding, deliberately not changed here

initializePython() in utilities/common/python.ts has no call sites, so onDidChangePythonInterpreterEvent is never fired and the onDidChangePythonInterpreter(() => restartLsp()) subscription in extension.ts is currently inert. Two consequences worth flagging:

• Changing the Python interpreter does not currently restart the server, so it keeps running under the old one.
• If that function is ever wired up as-is, it re-fires on every onDidChangeActiveEnvironmentPath without comparing against the path it last saw, which would reintroduce a restart storm.

I left it alone rather than widen this PR — happy to follow up if you'd like it wired up with a path comparison, or removed.

Test Plan

New unit tests, both in modules kept free of vscode imports so vitest can cover them in the test-vscode stage:

• configurationChange.test.ts — restarts for sqlmesh.projectPaths, sqlmesh.lspEntrypoint and python.defaultInterpreterPath; does not restart for editor.fontSize, workbench.colorTheme, files.autoSave, python.terminal.activateEnvironment, python.analysis.typeCheckingMode or terminal.integrated.env.linux. The last three are the regression tests for the terminal scenario in SQLMesh extension clashes with running sqlmesh in terminal #5642.
• coalesceAsync.test.ts — runs immediately when idle; four calls during a run collapse into exactly one rerun; every coalesced caller resolves; a later call still runs after a failure.

Ran both CI job commands locally:

$ pnpm run lint                                    # ui-style
exit 0

$ PLAYWRIGHT_SKIP_BROWSER_DOWNLOAD=1 pnpm run ci   # test-vscode
exit 0     # 18 unit tests pass (7 before this PR)

I have not reproduced the crash end to end in a live VS Code session — test-vscode-e2e is still disabled, and the trigger needs a real Python extension writing settings. The causal chain is established from the code path plus the reporter's process-of-elimination in #5642, and the unit tests pin the specific settings that must and must not cause a restart. Worth a sanity check from someone who can reproduce the original crash.

Checklist

• I have run make style and fixed any issues
• I have added tests for my changes (if applicable)
• All existing tests pass — ran the JS/TS suites via pnpm run ci; no Python changed, so make fast-test is unaffected by this PR
• My commits are signed off (git commit -s) per the DCO

cc @cmgoffena13 — picking this up per your note on #6054. Checked both issues for assignees and linked PRs beforehand; both were unassigned with nothing linked.