10.x: map each translator operand from its declared type, and sweep for it (port of #295) #433

Problem

The fix for #295 is on main (PR #432, merged as 9caa202) but not on release/10.x. There the translators still map an operand from what it isn't: a RangeSet operand that is neither the multirange nor the element becomes a range, a value set call's second operand a set, a factory's bounds the element, and an aggregate's source ranges. That's right for every overload that exists today, but an overload added later with another operand type would be translated wrongly, without an error. And nothing on this line would notice: 10.x has no TranslatorDispatchSweepTests.

#408 puts #295 ahead of #405, #406 and #191, so their 10.x cherry-picks are written under the sweep too.

Change

Cherry-pick 9caa202's commit with -x into a PR against release/10.x:

• MissingArm and the four translator changes (ValueRangesMethodCallTranslator, ValueSetsMethodCallTranslator, ValueRangesAggregateMethodCallTranslator, ValueSetsMemberTranslator).
• TranslatorDispatchSweepTests (conventions), MissingArmTests (EF translation tests), the oracle entry, the seed rangeset-overload-without-translator-arm.patch, the docs/oracles.md paragraph and the AGENTS.md lines.
• QueryMembers.Close/Mentions, which the 10.x translation-support port (10.x: translation-support inventory, every public query member classified and probed (port of #384) #430) also has.

Done when

On release/10.x, the sweep and MissingArmTests pass, the seed fails the sweep and leaves the EF translation tests green, and the four translators reverted make MissingArmTests fail. Checked on the EF floor and the newest-patch leg.

Release

Internal: no answer changes for any existing overload, and no public API change. Fixed only on release/10.x, so close it by hand.