search_ifr_flag_retry.js currently only covers standalone IFR flag kickback testing for $search and $searchMeta.

Sharded testing was initially removed because mongotmock's strict sequential command queue is fundamentally incompatible with the non-deterministic mongot interaction pattern that legacy $search/$searchMeta exhibits on sharded views.

Some pain points to consider: 

1. planShardedSearch namespace depends on view resolution timing. The command uses expCtx->getNamespaceString().coll(), which is the view name before resolution and the collection name after. Whether view resolution has occurred before planShardedSearch runs depends on the code path — with featureFlagSearchExtension=true, the extension dispatches first and the retry resolves the view before calling planShardedSearch (1 call with collection name); with flag=false, legacy runs from the start and calls planShardedSearch with the view name, then again with the collection name after view error retry (2 calls total).  
2. $searchMeta does not propagate viewName in the search command. prepareInternalSearchMetaMongotSpec doesn't set view info on the spec in the user-facing parsing path, so the search command sent to shards for $searchMeta lacks viewName. $search propagates it correctly. This means mock setup must differ between the two stages.                                                                         
3. Shared command queue with ordering sensitivity. planShardedSearch and per-shard search commands share the same mongotmock cursor response queue. Mocks must be queued in the exact order the server consumes them. Any change in call count (1 vs 2 planShardedSearch calls) or field content (viewName present or absent) causes the wrong mock to match the wrong command, producing hard failures.

$vectorSearch has no planShardedSearch step — it sends a single vectorSearch command per shard with deterministic fields, making mock setup straightforward regardless of topology.