Overview

IncrementalRolloutFeatureFlag's deleted-flag registry (consulted by IncrementalFeatureRolloutContext::fromWire to silently ignore removed IFR flags — scenario 2 of the wire-resolution table) has no production populator today. Only test helpers (registerDeletedIfrFlagForTest / clearDeletedIfrFlagsForTest) can add entries; the registry is empty in a running server.

Background

SERVER-130023 introduced IncrementalFeatureRolloutContext::fromWire and its scenario-based wire-resolution table. Scenario 2 (a wire-received flag name that was legitimately removed in an earlier version) depends on the deleted-flag registry being populated by whichever commit removes the flag. Without that, a flag removed from a newer binary but still sent by an older sender falls through to scenario 3 (unknown flag, same/older sender version) and fails with a protocol error instead of being silently dropped.

See PR #57081 and src/mongo/db/feature_flag.h/feature_flag.cpp (registerDeletedIfrFlagForTest, clearDeletedIfrFlagsForTest, getMutableDeletedIfrFlagRegistry).

Scope of Work

• Design a mechanism (e.g. an IDL-declared tombstone list, or a static registration alongside the removal of a flag's definition) so that deleting an IFR flag automatically registers its name as "deleted" in production builds.
• Update the doc comment on registerDeletedIfrFlagForTest/clearDeletedIfrFlagsForTest once this lands.

Acceptance Criteria

• Removing an IFR flag automatically registers its name as deleted without a manual runtime call.
• A wire-received flag matching a deleted name is silently ignored (scenario 2) in a real running server, not just in unit tests.