[CaffeinatedCoder]

Closes #349

Stacked on #352, which registers the disagreement as candidates. This PR removes the nine #349 entries, so merge #352 first; GitHub then retargets this PR to main.

Problem

BoundFunction declared lower() and upper() with argumentsPropagateNullability: [true], which tells EF Core the bound is NULL only when the column is. PostgreSQL also returns NULL for the empty range and for an unbounded side, as the in-memory LowerBound() and UpperBound() return null. So over a required column EF Core folded LowerBound() == null to WHERE FALSE, turned != null and HasValue into no filter, dropped the COALESCE of ?? fallback (open-ended rows fell out of a filter, and a projection threw Nullable object must have a value), and on a nullable column tested the bound with the column's own IS NULL. Every range type and RangeSet went through the same helper.

Change

• ValueRangesMethodCallTranslator.BoundFunction: argumentsPropagateNullability: [false], keeping nullable: true. That covers lower and upper on ranges and on RangeSet, and the discrete upper(x) - 1, which EF Core still reduces to upper(x) IS NULL when it is compared with null.
• ExecutedQueryTests.BoundsComparedWithNull_SelectTheRowsMemorySelects: each family now seeds every shape into its range column and, as a one-element multirange, into its RangeSet column (Seats/SeatBlocks, …, BillingPeriod/BillingPeriods), and runs all nine operations on both. The operations are written once over the bound and spliced onto x.LowerBound() and x.UpperBound() of each column.
• QueryTranslationTests: two tests pin the SQL without a database: lower(b."Period") IS NULL and upper(b."BlockedDays") IS NULL with no FALSE, and COALESCE(upper(b."Period") - 1, …).
• test/oracles/candidates.json: the nine LowerBound() and UpperBound() in a query: == null becomes WHERE FALSE and ?? max loses its COALESCE, because lower() and upper() are declared NULL only for a NULL argument #349 entries removed, 16 left. A null range answers some extensions in memory and throws on others, and the answers it gives disagree with PostgreSQL on a NULL column #350's twelve stay.
• test/oracles/claims.json: E70 now names RangeSet.LowerBound/UpperBound, says "range or multirange column", and quotes the new docs/efcore.md sentence below.
• docs/efcore.md: "So == null, HasValue and ?? on a bound select the same rows in a query as in memory, on a range or a RangeSet column."
• docs/migration.md: a new ## Migration from v10.x section with ### Check bound comparisons with null in queries (what changed per query form, and how to find the calls).
• Changelogs (root, EF Core, EF Core NodaTime): a ### Breaking line under [11.0.0-preview.1]. A silent fix into a major's preview goes under Breaking (ChangedAnswers_AppearOnlyInAMinor); the 10.x port gets the ### Changed answers row of its minor.

Tests

All local, SDK 11.0.100-rc.2.26504.105, Docker via OrbStack.

• With the fix, before removing the candidates: the bound sweep fails with exactly the nine candidate fixed: remove the entry … lines and no other row, the new RangeSet rows included.
• With the candidates removed: both sweeps pass (PredicatesOverANullableColumn still skips A null range answers some extensions in memory and throws on others, and the answers it gives disagree with PostgreSQL on a NULL column #350's twelve).
• Fix reverted ([true] back): the bound sweep fails on 234 rows, 117 on the range columns and 117 on the RangeSet columns, none of them a known candidate; for example LowerBound() == null on SeatBlocks (RangeSet<Int32Range>): server rows {}, memory rows {(,a] (,b] (,) empty}. Both new translation tests fail too. Restored afterwards.
• Full suite on postgres:16-alpine: all eight test projects pass (core 1397, NodaTime 238, EF 293, EF NodaTime 83, ASP.NET Core 92, conventions 407, integration 286, infinity-disabled 4).
• ExecutedQueryTests on postgres:18-alpine: 15/15.

Not covered here: the release/10.x port, which needs a 10.x minor with a ### Changed answers row; its own issue is filed separately.

🤖 Generated with Claude Code