Restore ggsql sessions after an extension host restart or window reload

[juliasilge]

Closes #506.

ggsql console sessions in Positron did not come back after an extension host restart or a window reload. R and Python sessions in the same window reconnected normally. Both of these are pretty important use cases:

• The extension host restarts every time you update any extension at all, which happens a lot.
• A window reload is really common on Workbench, when people leave a session and then come back.

Cause

Positron decides which extension owns a Positron API object from the file path of the caller of require('positron'). The extension reached the API through tryAcquirePositronApi() from @posit-dev/positron. That helper calls a global function that Positron defines in its own bootstrap file. The path of that file is inside no extension folder. Positron therefore recorded every ggsql runtime under nullExtensionDescription.

Positron uses this identity to activate the owning extension before it restores a session. For ggsql the activation failed, the error was logged at debug level, and the session was dropped.

R and Python use import * as positron from 'positron' inside their own source files, which Positron attributes correctly.

The fix

src/positronApi.ts now calls require('positron') directly, and esbuild.js marks positron as external. The call therefore stays in out/extension.js, which is inside the extension folder. Positron attributes it to ggsql.ggsql and the sessions can come back:

session-comes-back.mov

Five smaller changes are included as well:

• restoreSession accepts the sessionName that Positron passes, so a renamed session keeps its name across a restore.
• One getSupervisorApi() replaces three copies of the Positron Supervisor lookup.
• GgsqlRuntimeManager.alwaysRediscover is true. ggsql runtimes are never marked cacheable, so Positron must run discovery on every window open.
• A write-only session map is removed.
• ggsql-vscode/CLAUDE.md records why the API is acquired this way. It also documents the F5 dev workflow, and its guidance no longer points at tryAcquirePositronApi().

One behavior change

validateSession rejects when the Positron Supervisor extension is absent. It returned false before. Positron treats both as a failed validation. The rejection shows a restore-failure notice, where false discarded the session without a message. A user who disables the Supervisor now sees why the session did not come back.

Testing

The current suites run in stock VS Code, where no Positron API exists, so they cannot cover the restore path. src/test/bundle.test.ts asserts that require("positron") survives bundling, which is the half of the mechanism a unit test can currently reach. 29 tests pass.

We will get going on a set of extension tests for Positron specifically and will cover functionality like this then.