SmoMetadataProvider throws bare NullReferenceException when the current database cannot be resolved (Azure/Fabric endpoint)

Summary

SmoMetadataProvider.CreateConnectedProvider(...) throws an unhandled
System.NullReferenceException while building server metadata when the connection's
current database (Initial Catalog) does not resolve in the server's SMO database
collection. The exception surfaces with the useless message
"Object reference not set to an instance of an object." and no indication of which
database or what went wrong.

This bites tools that reuse SmoMetadataProvider for T-SQL IntelliSense / query
validation (Azure Data Studio, the VS Code SQL extension, and Fabric's Data Agent
"NL2SQL" example-query validation), against Azure SQL / Fabric SQL analytics endpoints.

Environment

• Component: Microsoft.SqlServer.Management.SmoMetadataProvider
• Source: reproduces against current main
  (src/Microsoft/SqlServer/Management/SmoMetadataProvider/Server.cs).
• Endpoint: Azure/Fabric SQL endpoint (ServerType == SqlAzureDatabase), connected mode.

Observed stack trace

System.NullReferenceException: Object reference not set to an instance of an object.
   at Microsoft.SqlServer.Management.SqlParser.MetadataProvider.DictionaryCollectionBase`2.Add(T item)
   at Microsoft.SqlServer.Management.SmoMetadataProvider.Server..ctor(Server smoMetadataObject, Boolean isConnected)
   at Microsoft.SqlServer.Management.SmoMetadataProvider.SmoMetadataProvider..ctor(Server server, Boolean isConnected)
   at Microsoft.SqlServer.Management.SmoMetadataProvider.ConnectedSmoMetadataProvider..ctor(ServerConnection ...)

Root cause (in current source)

In Server..ctor (Server.cs), for a SqlAzureDatabase endpoint smoMasterDb is forced
to null, so the constructor takes the "no access to master, only add the current
database" else-branch:

else
{
    var smoDb =
        this.m_smoMetadataObject.Databases[this.m_smoMetadataObject.ConnectionContext.DatabaseName];
    databases.Add(new Database(smoDb, this));   // no null-check on smoDb
}

The SMO Databases[name] indexer returns null when the current database cannot be
resolved by name (inaccessible, or the endpoint catalog does not expose that exact name).
smoDb is then wrapped and added with no null-check. The DatabaseObject<S,P> base ctor
(DatabaseObject.cs) guards its argument only with a Debug.Assert (compiled out of
Release builds), so it stores the null, and its Name getter dereferences it:

protected DatabaseObject(S smoMetadataObject, P parent)
{
    Debug.Assert(smoMetadataObject != null, ...); // no-op in Release
    this.m_smoMetadataObject = smoMetadataObject;  // stores null
}

public string Name => this.m_smoMetadataObject.Name; // NRE when null

DictionaryCollectionBase.Add reads the item's Name to key the collection, so the null
is dereferenced during Add — matching the reported stack.

Reproduction

A dependency-free program that models the exact code shape of Server.cs +
DatabaseObject.cs reproduces the NRE deterministically (run in Release so the
Debug.Assert is compiled out, as it is in shipped SMO):

• Case 1: current DB resolves → OK.
• Case 2: current DB does not resolve → System.NullReferenceException.
• Case 3: with a null-check → a clear "database not found / not accessible" error.

To reproduce against a live endpoint: call
SmoMetadataProvider.CreateConnectedProvider(new ServerConnection(sqlConn)) with an
Initial Catalog whose database is connectable but does not resolve in the enumerated
catalog.

Expected behavior

CreateConnectedProvider should not throw a bare NullReferenceException. When the
current database cannot be resolved it should either (a) throw a clear, typed exception
naming the database, or (b) skip the unresolved database gracefully (consistent with the
"only add the current database" intent).

Proposed fix

Null-check smoDb in the else-branch of Server..ctor before wrapping/adding it (and/or
make the DatabaseObject constructor throw on null instead of only Debug.Assert). Happy
to send a PR — would you prefer option (a) throw a typed error naming the database, or
option (b) skip + trace the unresolved database for graceful IntelliSense degradation?
I have both prepared.

Read src/Microsoft.SqlServer.Management.SmoMetadataProvider/Server.cs and DatabaseObject.cs, focusing on the SqlAzureDatabase branch and the database lookup before DictionaryCollectionBase.Add. Run the dependency-free reproduction in Release, then verify the chosen behavior for an unresolved current database—either a typed error naming it or graceful skipping with trace—and cover the resulting behavior with a regression test.