A Shift that lands a finite bound on the infinity sentinel keeps it there, so Shift(d).Shift(-d) != r #260

Problem

A finite bound shifted onto the value that stands for infinity stays there, so Shift(d).Shift(-d) != r:

• DateRange [9999-12-01,9999-12-29].Shift(1).Shift(-1) is [9999-12-01,9999-12-30].
• DateTimeRange [x, MaxValue-1tick).Shift(1tick).Shift(-1tick) ends at MaxValue.
• Live: a stored finite daterange '[2026-01-01,9999-12-30)', loaded, shifted +1 then −1 and saved, comes back as [2026-01-01,9999-12-31).

R28 promises "r.Shift(d).Shift(-d) == r for an exact step". It follows from #224 treating the sentinel as infinity (MoveKeepingInfinity, EndIsInfinity). The RangeArithmeticOracle row "a finite bound two steps below the maximum moves" checks only that nothing throws. Found by the final pre-release analysis on add665c (pass A).

Decision (maintainer, 2026-10-19)

A Shift or Expand that would land a finite bound on the value that stands for infinity throws OverflowException, as a move past an extreme already does. Landing there would silently turn a finite bound into infinity on save. A bound that already stands for infinity still stays where it is (#224).

Done when

[Max-3, Max-2].Shift(2) throws (where it would land on the sentinel), and [Max-3, Max-2].Shift(1).Shift(-1) == r, for each infinity-backed type (DateRange, DateTimeRange, DateTimeOffsetRange, LocalDateRange, LocalDateTimeRange, InstantRange, YearMonthRange). The RangeArithmeticOracle row asserts the round trip, and docs/ranges.md states the rule. Each test fails with the check removed.