JobServer constructor shouldn't run a SQL query

the JobServer class requires initializing its parent's Databases collection to construct itself:

 internal JobServer(Server parentsrv, ObjectKeyBase key, SqlSmoState state) : 
            base(key, state)
        {
            // even though we called with the parent collection of the column, we will 
            // place the JobServer under the right collection
            singletonParent = parentsrv as Server;
            
            // WATCH OUT! we are setting the m_server value here, because JobServer does
            // not live in a collection, but directly under the Database
            SetServerObject( parentsrv.GetServerObject());
            m_comparer = parentsrv.Databases["msdb"].StringComparer;
            jobCategories = null;
            alertCategories = null;
            operatorCategories = null;
            alertSystem = null;
            alerts = null;
            operators = null;
            targetServers = null;
            targetServerGroups = null;
            jobs = null;
            sharedSchedules = null;
        }

1. It shouldn't be making a SQL query of any kind in the constructor anyway
2. Populating the databases collection is hugely expensive
3. SqlSmoObject has a way to delay load StringComparer already that doesn't populate the collection, this object may just need a little refactoring of that method to support specifying msdb as the database to use for the query.

I found this by accident while trying to write a test for something else.
This code blows up because Databases["msdb"] doesn't exist:

var smoFilter = "[contains(@Name, 'SmoBaseline')]";
db.Parent.Databases.ClearAndInitialize($"[@Name='{Urn.EscapeString(db.Name)}']", Enumerable.Empty<string>());
db.Parent.Logins.ClearAndInitialize(smoFilter, Enumerable.Empty<string>());
db.Parent.LinkedServers.ClearAndInitialize(smoFilter, Enumerable.Empty<string>());
if (db.Parent.IsSupportedObject<JobServer>())
{
    db.Parent.JobServer.Jobs.ClearAndInitialize(smoFilter, Enumerable.Empty<string>());
}

Start at the JobServer constructor shown in the issue and inspect how parentsrv.Databases["msdb"] obtains StringComparer. Compare this with SqlSmoObject's existing delayed StringComparer loading, then use the provided ClearAndInitialize test scenario to verify that constructing JobServer does not populate Databases or fail when msdb is absent.