Polyfill: Fix extreme PlainYearMonth crash in non-ISO calendars

[craig-o-curtis]

Ports two tc39/proposal-temporal commits, one commit each:

• a41eb67 "Polyfill: Clamp ISO date to range in iterative calendar-to-ISO conversion" (from Bring polyfill in line with Intl Era Monthcode and update test262 commit tc39/proposal-temporal#3199)
• af0cb4b "Polyfill: Fix extreme PlainYearMonth crash in non-ISO calendars" (Polyfill: Fix extreme PlainYearMonth crash in non-ISO calendars tc39/proposal-temporal#3279, which fixes Polyfill: Exception incorrectly thrown with maximum allowed PlainYearMonth in some non-ISO calendars tc39/proposal-temporal#3251)

What was wrong

To convert a non-ISO calendar date to an ISO date, calendarToIsoDate() guesses an ISO date, converts the guess back to the calendar with Intl.DateTimeFormat, and corrects it. Near either end of the supported range, a guess can fall outside the range of the JavaScript Date object. Intl.DateTimeFormat can't format such a date, so the conversion threw RangeError: Invalid ISO date, even though the requested date itself is in range. On main, all of these throw:

Temporal.PlainDate.from({ calendar: 'hebrew', year: 279517, month: 10, day: 11 }, { overflow: 'reject' });
Temporal.PlainDate.from({ calendar: 'islamic-civil', year: -280804, month: 3, day: 21 }, { overflow: 'reject' });
Temporal.PlainYearMonth.from({ calendar: 'islamic-civil', year: 283583, monthCode: 'M06' });
Temporal.PlainYearMonth.from({ calendar: 'ethioaa', year: 281247, monthCode: 'M06' });
Temporal.PlainYearMonth.from({ calendar: 'indian', year: 275682, monthCode: 'M07' });

What this changes

• First commit: the first guess, and the correction after it, are clamped to the supported range (-271821-04-19 to +275760-09-13). This fixes the first two lines above.
• Second commit: for the islamic calendars, coptic/ethiopic/ethioaa, and indian, a guess outside the Date range is moved into range by whole calendar cycles (islamic 10631 days = 30 years, coptic/ethiopic/ethioaa 1461 days = 4 years, indian 4 years), converted, and the year moved back. This fixes the last three lines. It also fixes islamic-civil until() near both ends of the range, which threw on main. Dates inside the range take the same code path as before.

Not fixed by this PR

These behave the same on main and on this branch:

• hebrew and persian near the end of the range: until()/since() and Duration.prototype.round() with relativeTo can still throw Invalid ISO date. For example, persian +275760-07-01 until +275760-09-13 with largestUnit: 'months', or Temporal.Duration.from('P40D').round({ largestUnit: 'months', relativeTo: { calendar: 'hebrew', year: 279517, month: 8, day: 15 } }). proposal-temporal's polyfill has the same problem, so I'll report it there first.
• chinese and dangi far from the present: years like 250000 throw TypeError: Internal error. Icu error. from ICU. proposal-temporal fixed this in Polyfill: fix Chinese/Dangi calendar at extreme date ranges tc39/proposal-temporal#3277 (for Coverage gap: Incorrect behaviour at end of range for Chinese calendar tc39/proposal-temporal#3081), which isn't ported here. Also, under ICU 78 these calendars currently fail even for ordinary years (Bug: Malformed leap month suffix while implementing Chinese calendar #360); April 2026 rebase, part 3 #361 fixes that.

Testing

Node 24.21.0 (ICU 78.3, CLDR 48): jest passes, and test262 at the pinned version passes with no new failures or unexpected passes (intl402/Temporal 330 passed, 8 expected failures; built-ins/Temporal 4330 passed).

The test262 tests for this fix, intl402/Temporal/{PlainDate,PlainDateTime,PlainYearMonth,ZonedDateTime}/from/extreme-dates.js and .../prototype/withCalendar/extreme-dates.js, are newer than our pinned test262. I ran them by hand, at the test262 commit proposal-temporal used for af0cb4b, and counted each calendar row separately:

Build	Failing rows (of 112)
main	59
this PR	42
this PR with #361 applied on top	8

With this PR, every remaining failure is one of the "Not fixed by this PR" items or is fixed by #361: indian before year 1, hebrew negative leap years, the coptic/ethiopic eras, and chinese/dangi under ICU 78. With #361 on top (it applies cleanly), only the chinese/dangi far-future and far-past rows fail. Upstream's removal of PlainYearMonth/from/extreme-dates.js from its expected failures needs no change here, because that test isn't in our pinned test262.

Differences from upstream (TypeScript)

• The shifted isoToCalendarDate functions call HelperBase.prototype.isoToCalendarDate, where upstream calls nonIsoHelperBase.isoToCalendarDate.
• They are installed as override class fields, the same way OrthodoxBaseHelper already installs OrthodoxOps.
• ES.AddDaysToISODate is this file's addDaysISO.