A shard server may receive a request with IFR metadata containing per-request flag values. A normal request forwarded by a current mongos includes this metadata, while direct requests and requests from older components may not.

When a shard receives a request without IFR metadata, it conservatively overrides to `false` every IFR flag whose serialization version is greater than `kLastLTS`. This prevents rollout behavior from being enabled without coordination from the request sender. The node's process-wide flag values are not changed.

`BM_FIND_ONE` sends requests directly to a shard-server fixture without IFR metadata, so it exercises this fallback as its primary path.

Before SERVER-129707, `kLastLTS` was 8.0. Three IFR flags had serialization versions greater than 8.0, so the per-request fallback context contained three `false` overrides.

After SERVER-129707, `kLastLTS` became 9.0. Those flags have serialization versions of 8.3 or 9.0, so none satisfy the strict `version > kLastLTS` condition. The fallback context therefore contains no overrides, and the flags use their local defaults.

The instruction-count improvement comes from cloning an empty per-request fallback context instead of one containing three map entries. The benchmark exposes this compatibility-path cost as a CRUD performance change because it does not model the normal mongos-to-shard request path.

Suggested Path Forward

Update `BM_FIND_ONE` to include realistic IFR metadata so it exercises the normal mongos-to-shard path rather than the missing-metadata fallback.

Retain separate coverage for the fallback path under an explicit benchmark such as `BM_FIND_ONE_NO_IFR`. This keeps compatibility-path performance visible without presenting it as the primary CRUD behavior.