[CaffeinatedCoder]

Closes #384

Stacked on #383 (it reuses the composition helpers and touches the same registry files); review that one first.

Problem

postgres-surface.json inventories PostgreSQL's side. Nothing inventoried the C# side: which public members a query can call, and whether EF Core runs each one as SQL. docs/efcore.md#what-runs-where lists both halves by hand, and a member in neither table (a new overload, a generic family, a member the docs never mention) had no stated support. A member whose translation disappeared or appeared was noticed only if a hand-written test called it. The composition sweeps counted Clamp as "untranslated" without saying whether that was intended.

Change

• QueryMembers (conventions project, linked into the integration project): discovered from the public API, not from the translators. Every public method and instance property of a public, non-nested type of the two libraries whose receiver, a parameter or the result is a range, a multirange or a value set. One key per overload, with generic families kept generic. Converters, static constants and overloads an expression tree cannot hold (ReadOnlySpan<char>, out) are left out by rule. That gives 813 keys.
• test/oracles/translation-support.json: 36 entries, first match wins: server, client (with the reason) or planned (with the issue). Every classification comes from the docs, or says plainly that the docs don't mention the member.
• TranslationSupportInventoryTests (conventions, no database): every key is classified, no entry is stale, and every entry carries what its support needs. A new public member fails CI until it is classified.
• TranslationSupportProbeTests (integration): 2,254 member × type cells over 13 range and 34 value set types, about 12 s. Each call takes a column as an operand. It first runs where the server must evaluate it: a filter for a predicate, a null test for a value that can be NULL, an ordering for one that can't (EF Core folds (int?)x == null away untranslated), and HAVING for an aggregate. Then it runs in a final projection. Both are compared with memory over the rows as loaded.
• Registered in oracles.json, named in E30/E31 heldBy, described in docs/oracles.md and AGENTS.md.

What it found

• RangeLowerBoundComparer.Compare runs as SQL in the range order: EF Core rewrites any Compare(a, b) to the natural comparison #385 (new, silent, low): EF Core rewrites any Compare(a, b) to the natural comparison. So RangeLowerBoundComparer<TRange, T>.Instance.Compare(r.Period, p) runs as SQL in the full range order. Where(… == 0) drops ranges that share p's lower bound. It is registered as a candidate. The root cause is EF Core's: a comparer that reverses int order gets the same treatment. Reporting that upstream is separate.
• Everything else agrees with the docs: 1,656 cells run as SQL with memory's answers, and 598 run in memory only and project memory's answers.

Members docs/efcore.md#what-runs-where doesn't mention (classified from what the probe shows; listed for a docs decision)

• Runs as SQL: Equals(T) and Equals(object) on ranges, RangeSet and value sets.
• In memory only: RangeSet.Count, the RangeSet indexer, Values on a value set, GetEnumerator, From, Parse, ToString, GetHashCode, the NodaTime interop conversions (ToDateInterval, ToInterval, ToInstantRange, ToLocalDateRange, ToYearMonthRange), and RangeLowerBoundComparer.Compare (RangeLowerBoundComparer.Compare runs as SQL in the range order: EF Core rewrites any Compare(a, b) to the natural comparison #385).

The docs call the calendar factories (Month, Quarter, Year, IsoWeek with a column argument) "not translated yet" but no issue tracks them, so they're classified client, not planned.

Tests

• TranslationSupportInventoryTests 3/3; conventions project 412/412.
• TranslationSupportProbeTests passes on PostgreSQL 16 and 18 with the RangeLowerBoundComparer.Compare runs as SQL in the range order: EF Core rewrites any Compare(a, b) to the natural comparison #385 candidate; integration project 301/301 on both.
• Seed merge-translation-dropped.patch (the range translator stops translating Merge): CAUGHT by TranslationSupportProbeTests as "classified server, but refused" on every range type.
• While building it, three probe artifacts were fixed in the harness, not reported: an explicit Convert to the interface parameter (C# passes the column without one), CultureInfo as a constant in a client projection, and sub-microsecond probe elements (the store's truncation is TemporalStoreParityTests' to judge).

🤖 Generated with Claude Code