testPerformShardedClusterRollingRestart/testPerformUpgradeSharded in jstests/multiVersion/libs/mixed_version_sharded_fixture_test.js drives an IFR feature flag through these stages:

1. All binaries last‑LTS
2. Rolling binary upgrade (configs → secondary shards → primary shards → mongos)
3. Latest binaries, FCV=lastLTS
4. whenOnlyRouterHasIFRFlag — router flag on, shards flag off
5. whenOnlyShardHasIFRFlag — router flag off, shards flag on
6. whenIfrFlagsAreToggled — flag on everywhere
7. FCV bump to latest, then FCV downgrade

Stages 4 and 5 correspond directly to the rollout lifecycle of an IFR flag: you toggle it independently on the router and the shards to validate that inconsistent states behave correctly during a real rollout. That's exactly right for a flag whose incremental_rollout_phase is rollout.

But featureFlagSearchExtension is in the release phase — its default is true on any latest binary, and in production it will never realistically be flipped off. So driving it through stages 4/5 exercises states that will never happen in the wild:

• Stages 4 and 5 need explicit setParameter calls to force the flag off; that's the only way to get there.
• Stage 3 (whenBinariesAreLatestAndFCVIsLastLTS, first invocation) runs with the flag already on (default true), so the "before toggling" observation doesn't cover anything meaningful for a release‑phase flag — it's already at its production default.
• The whenOnlyShardHasIFRFlag stage in particular forced us to discover this test's incorrect assumption about wire installs and view‑definition dispatch (see the sibling fix). The bug was real, but the state that surfaced it is one production never reaches for this flag.

Requested: a testPerformUpgradeShardedReleasePhaseFlag variant (or extra flag on the existing helper) that skips the per‑side toggling and instead asserts the behaviors relevant to a flag that goes straight from in_development → release:

• Legacy behavior on last‑LTS binaries at every FCV.
• Extension behavior as soon as a node is on the latest binary (since IFR flags are not FCV‑gated).
• Wire IFR mechanics validated once, in the "all latest, all defaults" state, without the artificial router‑only / shard‑only toggles.

The existing rollout‑shaped harness stays; this just gives release‑phase flags a shape that matches their production lifecycle.