[Feature Request]:Future integration to upport WSL Containers (wslc) as a runtime alternative to Docker Desktop for MSSQL extension's Local SQL Server Container

Nobody has claimed this yet.

### Feature Description

Use case

The MSSQL extension's Local SQL Server Container feature lets developers create and manage SQL Server containers from within VS Code without writing Docker commands. However, it currently requires Docker Desktop (or an unspecified "equivalent") running in Linux container mode. With Microsoft's own WSL Containers (wslc) now in public preview

A native, first-party container runtime built into WSL2 that requires no separate installer
Developers working in WSL should be able to use this native runtime instead of installing/running Docker Desktop.
Current workaround

None available today within the extension. Developers on WSL who want a Docker-free setup have to either install Docker Desktop anyway (defeating the purpose of a lightweight, native workflow) or fall back to manual wslc commands outside the MSSQL extension entirely — losing the guided wizard, auto-connect, and container lifecycle management the extension provides.

Proposed behavior

Detect and support wslc as a valid container runtime alongside Docker Desktop when the extension checks for prerequisites
Allow the Local SQL Server Container wizard to provision, start, stop, and manage containers via wslc when running inside WSL2, without requiring Docker Desktop to be installed or running
Since wslc's CLI is designed to closely mirror the Docker CLI, evaluate whether the extension's existing Docker integration can be extended/abstracted to target either runtime with minimal divergence
Who benefits

All developers

Urgency

Nice to have

Additional context

WSL Containers entered public preview in late June 2026 and is expected to reach general availability in fall 2026. Current tooling gaps (e.g., no Docker Compose support yet) mean this may need to be scoped as "supported once wslc reaches feature parity for basic container lifecycle operations" rather than immediate full parity — but the direction is aligned with Microsoft's own platform investment.

User story>

As a developer, I want to use WSL Containers (wslc) instead of Docker Desktop with the MSSQL extension's Local SQL Server Container feature, so that I can provision SQL Server containers without installing Docker Desktop.
As a developer using VS Code on Windows with WSL2
I want the MSSQL extension's Local SQL Server Container wizard to support wslc as a container runtime
So that I can create and manage SQL Server containers using Microsoft's native, first-party container runtime instead of depending on Docker Desktop

Acceptance Criteria:

Given wslc is available and running in WSL2, when the extension checks for a container runtime, then it detects wslc as a valid option (not just Docker Desktop).
Given wslc is selected/detected, when a developer creates a Local SQL Server Container, then it provisions successfully using wslc without requiring Docker Desktop to be installed.
Given a container is running via wslc, when using the Connections view, then start/stop/delete lifecycle actions work the same as they do for Docker-backed containers.
Given wslc lacks a capability the extension relies on (e.g., a specific network or volume feature), when that gap is hit, then the extension surfaces a clear message rather than failing silently.

### Problem and Motivation

The MSSQL extension's Local SQL Server Container feature lets developers create and manage SQL Server containers from within VS Code without writing Docker commands. However, it currently requires Docker Desktop (or an unspecified "equivalent") running in Linux container mode. With Microsoft's own WSL Containers (wslc) now in public preview

Additional context

WSL Containers entered public preview in late June 2026 and is expected to reach general availability in fall 2026. Current tooling gaps (e.g., no Docker Compose support yet) mean this may need to be scoped as "supported once wslc reaches feature parity for basic container lifecycle operations" rather than immediate full parity — but the direction is aligned with Microsoft's own platform investment.

### Related Area

- [ ] Connection dialog (SQL Server | Azure browse/Fabric browse)
- [ ] Query editor
- [ ] Query results panel
- [ ] Object Explorer
- [ ] GitHub Copilot integration
- [ ] Preview/Edit data
- [ ] Table Designer
- [ ] Schema Designer
- [ ] Schema Compare
- [x] Local SQL Server Container provisioning
- [ ] SQL database in Fabric provisioning
- [ ] DACPAC/BACPAC export/import
- [ ] SQL Database projects
- [ ] Query Plan Visualizer
- [x] Other (please describe below)

### If you selected "Other", please describe the area

None available today within the extension. Developers on WSL who want a Docker-free setup have to either install Docker Desktop anyway (defeating the purpose of a lightweight, native workflow) or fall back to manual wslc commands outside the MSSQL extension entirely — losing the guided wizard, auto-connect, and container lifecycle management the extension provides.

### Confirmation

- [x] I have searched existing feature requests and couldn't find a match
- [ ] I want to help implement this feature

Start by tracing the Local SQL Server Container prerequisite checks, wizard, and Connections view lifecycle actions, then compare the existing Docker integration with wslc's available CLI capabilities. Done means detecting wslc in WSL2, provisioning and managing containers without Docker Desktop, and showing a clear message when a required capability is unavailable.

Written by the indexing model from the issue text.