A discrete range read as [x,infinity) loses 9999-12-31; UpperBound disagrees between memory and server #117

A discrete range stored with an exclusive infinity upper bound — the form another tool writes with daterange('2024-01-01','infinity'), since [) is the constructor's default — loads one day short, and UpperBound() answers differently in memory and on the server. Measured on main (7f4dc47) against PostgreSQL 17.11:

stored:  daterange('2024-01-01','infinity')  →  [2024-01-01,infinity)   upper_inc = f
loads:   DateRange [2024-01-01,9999-12-30]       LocalDateRange [2024-01-01,9999-12-30]

UpperBound():              memory 9999-12-30   server 9999-12-31  (upper(x) - 1 is still infinity, which Npgsql reads as MaxValue)
UpperBoundInclusive():     memory true         server true
PostgreSQL itself:         daterange('2024-01-01','infinity') @> '9999-12-31'::date  →  t

The range the database holds contains 9999-12-31; the loaded value doesn't. Contains(DateOnly.MaxValue) agrees between memory and server (both false) only because the parameter goes out as infinity, which the exclusive bound excludes — so a query can't even ask the server the question PostgreSQL answers with t.

Cause. RangeProviderConversion.FromProvider calls CreateFinite(lower, DateOnly.MaxValue, true, false) for the infinity) bound, and the discrete canonicalization steps the exclusive upper bound back a day. The plugin's own writes are unaffected: a closed [x, 9999-12-31] goes out as [x,infinity] (inclusive) and reads back exactly; TemporalStoreParityTests holds that. Rows written by other tools in the [x,infinity) form are the gap. LocalDateRange behaves the same; YearMonthRange throws instead (loud).

Fix (10.0.0): in FromProvider, for a discrete type whose extreme Npgsql maps to infinity, read an exclusive upper bound at MaxValue as inclusive MaxValue (the special infinity lies beyond the element domain, so "everything below infinity" is "everything up to MaxValue"), and mirror it for -infinity on the lower side. Changes what a row loads as → breaking. The alternative is to document it under docs/efcore.md#rows-written-by-other-tools and keep the one-day loss.

Tests: an integration row inserted as daterange(x, 'infinity') (and '-infinity', and the LocalDateRange / tsrange / tstzrange forms) read through EF and compared with upper(x), upper_inc(x) and x @> max on the server.

Found in the 10.0.0 bug hunt (code-analyst reading, reproduced here). Narrow — only rows another writer produced in that form — hence low.

Also on the literal and JSON-document paths (added 2026-10-18, from LiteralCorpusProbeTests, #135). RangeFormat.Parse hands the same bounds to CreateFinite, so the column fix alone won't close this. Against postgres:17:

LocalDateRange behaves the same, except that its lower-side form [-9998-01-02,…] is refused by the server when written back (loud). The same holds for both multiranges. Inclusive infinite bounds ([x,infinity], [-infinity,x)) and the continuous types agree.