This section details on the original issue you should resolve

<issue_title>Keeps running while in transaction</issue_title>
<issue_description>
Type:Bug

begin tran
delete command
exec sp
select
while committing (or even on previous commands), the editor keep "executing query"

Extension version: 1.30.0
VS Code version: Code 1.99.2 (4949701c880d4bdb949e3c0e6b400288da7f474b, 2025-04-10T01:21:25.295Z)
OS version: Windows_NT x64 10.0.26100
Modes:

vsliv368:30146709vspor879:30202332vspor708:30202333vspor363:30204092vscod805cf:30301675binariesv615:30325510c4g48928:30535728azure-dev_surveyone:30548225a9j8j154:30646983962ge761:309597992e7ec940:31000449pythontbext0:30879054cppperfnew:31000557dwnewjupyter:31046869pythonrstrctxt:31112756nativeloc1:311922155fd0e150:31155592dwcopilot:311700136074i472:31201624dwoutputs:31242946customenabled:31248079hdaa2157:31222309copilot_t_ci:31222730e5gg6876:31282496pythoneinst12cf:31262606bgtreat:312685684gafe986:3127182631787653:312621863e8i5726:3127174749da9784:31282606useunpkgapi:31280918747dc170:31275177aj496949:31278748aj953862:31281341

<agent_instructions>Problem Statement
When a user opens the same SQL file in multiple editor instances (tabs, split views, or windows), all editors share the same query execution state and SQL Server session (SPID). This causes critical UI state synchronization issues:

Primary Issue - Shared Execution State:
When multiple tabs/editors are open for the same file and they share the same SPID:

Tab 1 executes a query that starts a transaction (e.g., BEGIN TRANSACTION; UPDATE table SET column = value;)
Tab 2 executes a different query (e.g., SELECT * FROM another_table;)
Problem: Tab 2's query completes successfully and returns results, BUT the UI shows the query as still "executing" indefinitely because Tab 1's transaction hasn't been committed
The execution state is shared between both tabs, so Tab 1's active transaction causes Tab 2's UI to remain in "executing" state even though Tab 2's query finished
Secondary Issue - Session Sharing:
Both editors use the same SQL Server session (SPID), which means:

Any transaction state from one editor affects the other
Query execution contexts are not isolated
Users cannot work independently in different tabs of the same file
Reproduction Steps:

Open a SQL file (e.g., test.sql)
Split the editor or open the same file in a second tab
In Tab 1: Execute BEGIN TRANSACTION; UPDATE table SET column = value; (leaves transaction open)
In Tab 2: Execute SELECT * FROM another_table; (different query, no locks needed)
Result: Tab 2 gets query results successfully, but the UI shows "executing..." indefinitely until Tab 1 commits the transaction
Root Cause
The extension currently keys all connection state, query runners, and execution state tracking by document URI only. When multiple editors view the same document, they all share:

The same QueryRunner instance
The same execution state tracking in SqlOutputContentProvider
The same SQL Server session (SPID)
The same status bar state in StatusView
This means UI updates and execution state from one editor instance overwrite or interfere with another editor's state.

Required Solution
Implement per-editor-instance isolation for query execution state and SQL Server sessions while maintaining shared connection profiles:

Generate unique editor instance keys using both document URI and VS Code's viewColumn property (e.g., "file:///path/to/file.sql::1", "file:///path/to/file.sql::2")

Separate connection sharing from execution context: Connection credentials can be shared, but each editor instance must get:

Its own QueryRunner with independent execution state tracking
Its own SQL Server session (SPID) for query execution
Its own status bar state showing query execution status
Update state management across these components:

ConnectionManager: Track execution contexts per editor instance while sharing connection profiles
SqlOutputContentProvider: Key query runners by editor instance, not just document URI - each editor needs its own QueryRunnerState
QueryRunner: Us...