`ShardingTest.waitUntilStable()` did not wait for routers and shards to rediscover the config
server after it restarts, so it could return while mongos still had the config node marked
`Unknown`. The first operation routed through mongos then triggered a `ShardRegistry` reload that
failed with `FailedToSatisfyReadPreference`.

`configRS.awaitSecondaryNodes()` only reflects the nodes' own state, and the `awaitRSClientHosts()`
propagation loop in `jstests/multiVersion/libs/multi_cluster.js` was passed `shardPrimaries` only —
the config replica set was never included. This adds the config primary to that wait.

Adds `jstests/sharding/shardingtest_wait_until_stable_config_rsm.js`, which makes the gap
deterministic rather than racing a real restart: it holds mongos's view of the config server in
`Unknown` using a `failCommand` failpoint on `hello` targeted at mongos's `appName`, leaving the
shell's and the shards' connections intact. Also adds missing `OWNERS.yml` entries for
`multi_cluster.js` and the new test.