Currently, the analyzeShardKey command doesn't participate in shard versioning when it is sent to a secondary since:

1. On secondaries, the database and shard version check is only performed for commands that specify a readConcern (that is not "available").
2. When constructing analyzeShardKey command to forward to a shard, mongos attaches the database version and shard version as necessary but it doesn't attach a readConcern since the analyzeShardKey command only supports readConcern "local" anyway.

Given (1), mongos should explicitly attach the readConcern to "local" to the analyzeShardKey command to a shard.

Similarly, the configureQueryAnalyzer command currently runs $listCollections command against the primary shard. However, it doesn't have the logic to refresh and retry on a StaleDbVersion error.