Resolve SDK from project.assets.json (NuGet cache) instead of requiring .nupkg #27

Priority: P0

Problem

The LSP server currently requires a .nupkg\ file to build its \SdkIndex. External customers install the SDK via <PackageReference>\ — the package lands in their NuGet cache (e.g., ~/.nuget/packages/microsoft.azure.connectors.sdk/0.4.0-preview.1/) with both:

• The .nupkg\ archive
• Pre-extracted DLLs at \lib/net8.0/Microsoft.Azure.Connectors.Sdk.dll\

Without the SDK index, all intelligent features are disabled: ConnectorName completions, trigger operation suggestions, CodeLens, hover, and code actions.

Proposed Solution

Server-side: \SdkIndex.TryCreateFromAssemblyAsync(string dllPath)\

Add a new factory method that creates the index directly from a DLL path (no nupkg extraction needed). The existing \MetadataReader.DiscoverTypes\ already works on DLL paths — this is mostly plumbing.

Server-side: --sdk-assembly\ CLI argument

Accept --sdk-assembly /path/to/Microsoft.Azure.Connectors.Sdk.dll\ in \ResolveSdkPath\ as an alternative to --sdk /path/to/file.nupkg.

Server-side: Auto-discover from \project.assets.json\

When neither --sdk\ nor --sdk-assembly\ is provided, the server can defer SDK discovery until the first document is opened. At that point, it already knows the document's project directory (used by \FindProjectDirectory\ in the HoverHandler). Parse the project's \obj/project.assets.json\ to find the \Microsoft.Azure.Connectors.Sdk\ package entry and resolve the DLL path from the NuGet cache.

Alternatively, the extension can perform this discovery and pass the DLL path via --sdk-assembly\ (see companion issue for extension changes).

Acceptance Criteria

• \SdkIndex.TryCreateFromAssemblyAsync(string dllPath)\ creates an index from a single DLL
• --sdk-assembly\ CLI argument accepted alongside --sdk\
• When no CLI args provided, server discovers SDK from workspace project's \project.assets.json\
• All existing tests pass
• Existing --sdk nupkg\ path continues to work (backward compatible)