10.x: translation-support inventory, every public query member classified and probed (port of #384) #430

Problem

The 10.3.0 additions (#405, #406, #191) are done only when test/oracles/translation-support.json classifies them server and the translation-support probe passes (#408). That inventory is #384, and it doesn't exist on release/10.x. So none of the 10.3.0 cherry-picks can meet its own "done when", and a 10.x public member whose translation appears or disappears is still noticed only if a hand-written test calls it.

The inventory has already been run on this line. On 2026-10-25, PR #386's classification and probe ran without changes on a scratch release/10.x checkout (03c04e4, not committed), on EF Core 10.0.0 and on 10.0.13 with Npgsql 10.0.3. They gave the same 2,256 cells as main, and the 10.x public API was fully classified. The only failures were #385's 13 cells (26 lines), which 10.x's candidates.json doesn't register (comment on #384).

Change

Once #384 is on main, cherry-pick it with -x into a PR against release/10.x:

• QueryMembers, TranslationSupportInventoryTests, TranslationSupport.cs, translation-support.json, TranslationSupportProbeTests, the oracle entry and its seed (merge-translation-dropped.patch), the claims and the docs/oracles.md section.
• The composition helpers from test: composition sweeps — outer joins, nullable operand pairs, quantifiers, repeated execution, filtered aggregates, declared nullability (#375–#380) #383 that the probe reuses. test: composition sweeps — outer joins, nullable operand pairs, quantifiers, repeated execution, filtered aggregates, declared nullability (#375–#380) #383's sweeps aren't on this line, so take only what the probe needs.
• Register RangeLowerBoundComparer.Compare runs as SQL in the range order: EF Core rewrites any Compare(a, b) to the natural comparison #385's cells in 10.x's candidates.json against 10.x: RangeLowerBoundComparer.Compare in a query runs in the range order (port of #385) #396, the 10.x issue for that defect. They report candidate fixed when 10.x: RangeLowerBoundComparer.Compare in a query runs in the range order (port of #385) #396 lands, and are removed then.
• Keep the classification the same as main's, except where 10.x's API or docs really differ. Note each difference in the PR.

Done when

TranslationSupportInventoryTests and TranslationSupportProbeTests pass on release/10.x on the floor and newest-patch legs. The seed fails the probe (dotnet run tools/oracles.cs seeds). The port lands before #405, #406 and #191 are picked, so each of those moves its own entry to server.

Release

Tests only, with no package change and no changed answer. Fixed only on release/10.x, so close it by hand.