[Feature]: DataProvider Migrations UI

[MelbourneDeveloper]

Problem / motivation

SharpLsp has no first-party, open database-schema workflow. As noted in the related comment on #157, Microsoft has not open-sourced the SQL Server project engine, so SSDT/.sqlproj compatibility is not a viable path under SharpLsp's zero-proprietary-dependency rule.

DataProvider Migrations provides the open, database-agnostic alternative. It needs a first-class editor experience instead of being only a separate CLI workflow.

Proposed solution

Bake a DataProvider Migrations experience into SharpLsp and its VS Code extension:

• Discover DataProvider YAML migration schemas in the workspace and surface them in Solution Explorer.
• Provide commands/UI to create and open schemas, validate them, preview schema-diff/generated migration operations, and run DataProviderMigrate migrate.
• Surface migration progress, diagnostics, failures, and actionable fixes in the editor.
• Support secure target/provider and connection configuration through SharpLsp's existing configuration conventions.
• Refresh the UI and diagnostics when schemas or workspace configuration change.
• Integrate the migrate and export workflows, including clear provider-capability status.

Initial providers should match DataProvider Migrations today: SQLite and PostgreSQL. SQL Server support is explicitly deferred until Nimblesite.DataProvider.Migration.SqlServer exists.

This is a DataProvider-native migration workflow, not a compatibility layer for .sqlproj, SSDT, DacFx, or DACPACs.

Language relevance

Editor/tooling feature; YAML migration schemas, with SQLite and PostgreSQL initially.

Alternatives considered

• .sqlproj/SSDT/DacFx integration: rejected because the underlying database-project engine is proprietary and supporting it independently would require a ground-up reimplementation.
• DataProviderMigrate CLI only: remains supported, but does not provide workspace discovery, live diagnostics, diff preview, or in-editor migration execution.