Register #349 and #350 as candidates in ExecutedQueryTests, and claim the bound-null sentence of docs/efcore.md #351

Problem

#349 and #350 were found by a consumer's differential probe, not by an oracle here. Nothing in ExecutedQueryTests compares LowerBound() or UpperBound() with null inside a query (MergeAndBoundAccessors_MatchInMemory only projects them), nothing runs a range predicate over a nullable range column, and no claim quotes the sentence in docs/efcore.md that #349 contradicts:

LowerBound() and UpperBound() return T?. PostgreSQL's lower and upper return NULL for an unbounded or empty range, and the in-memory methods match that.

So neither fix would be proven by the suite, and nothing would force a registry entry out when the fix lands.

Change

• ExecutedQueryTests gets two sweeps that end in Candidates.Verdict:
  • for 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, every bound operation from the issue (compared with null, HasValue, ?? in a filter and in a projection, a filter on a projected bound), over rows of every shape in a range column of every family, against LINQ over the rows as loaded;
  • for 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, the twelve predicates from the issue over a nullable DateRange column holding NULL and every shape, in a database of its own.
• test/oracles/candidates.json gets one candidate per operation, scoped by method.
• test/oracles/claims.json gets an E claim quoting the sentence above, held by ExecutedQueryTests.

The fixes themselves and the release/10.x port are separate.