Make repeated DST times configurable in Cron and Schedule.cron - #9905

When clocks fall back, Cron.next and Schedule.cron only fire on the first occurrence of the repeated local hour. A */5 * * * * Europe/Berlin schedule therefore has a 65-minute gap on the night of 2026-10-25. This PR adds an opt-in policy for which occurrences to include. Existing schedules behave the same as before unless they set the option.

const cron = Cron.parseUnsafe("*/5 * * * *", "Europe/Berlin", { repeatedTimes: "both" })
Cron.next(cron, new Date("2026-10-25T00:55:00Z")) // 2026-10-25T01:00:00.000Z (default: 02:00Z)

Schedule.cron("*/5 * * * *", "Europe/Berlin", { repeatedTimes: "both" })

API

• New type Cron.RepeatedTimesPolicy = "earlier" | "later" | "both".
• New repeatedTimes field on Cron, defaulting to "earlier" (the current behavior). make, parse and parseUnsafe accept it, and so does the string form of Schedule.cron. A pre-parsed Cron passed to Schedule.cron keeps its own policy.
• The policy is stored on the Cron value, like tz, so next, prev, sequence, both Schedule.cron overloads and ClusterCron all use it without any signature changes. Equivalence, Hash and toJSON/toString include it. format and match don't change.

Semantics

For every policy, next returns the earliest matching instant strictly after its input and prev the latest strictly before it. Under "both", the two occurrences come out in order with no duplicates. UTC and fixed-offset zones behave the same under every policy. The search no longer assumes a fold lasts one hour; Casey's three-hour fold and Lord Howe's 30-minute fold are covered.

This also fixes prev when it starts inside the second occurrence. On main, prev from 2026-10-25T01:07Z (Berlin */5) returns 00:05Z instead of 00:55Z, and a daily 0 30 2 * * * comes back a day early.

Gap limitations

The policy only applies to repeated times. Local times skipped when clocks move forward are handled the same under every policy: a matching time inside the gap resolves to the instant after the gap.

Near a gap, prev on main could throw "Unable to find cron date" (0 30 2 * * * Berlin on 2026-03-29) or return an instant after its input (30 * * * * from 01:20Z returned 01:30Z). It now returns an instant strictly before its input in both cases.

Near a gap, next and prev still aren't guaranteed to return the nearest matching instant. For example, in Australia/Lord_Howe 5,20,40 2 * * *, prev from 2026-10-03T15:55Z returns 15:40Z, not 15:50Z, because candidates are searched in wall-clock order. That behavior is inherited from main and deferred here. The RepeatedTimesPolicy docs and the changeset say so.

Performance

Inside a fold, a candidate that falls on the wrong side of the input is no longer skipped one second at a time. Within a single fold, later wall times always resolve to later instants. So the search checks that the candidate one fold length further on is in range, then binary-searches for the first in-range second. Gaps, where that ordering doesn't hold, keep the one-second step.

For * * * * * *, calls that start inside a fold went from 17–260 ms to under 1 ms (Berlin, Casey and Lord Howe, both directions, all policies). This also covers the default policy: next from inside the second occurrence cost about 72 ms in Berlin and about 200 ms in Casey on main.

Validation

• Cron, Schedule and ClusterCron tests: 90/90 pass. Doc examples for Cron.ts and Schedule.ts: 42/42 pass.
• tsc -b tsconfig.json: no errors. oxlint and dprint pass.
• A brute-force oracle (throwaway, not committed) listed every matching second around the Berlin, Casey and Lord Howe folds and checked next/prev under every policy: 8,870 checks, 0 mismatches. An independent review oracle that also covered Havana and fractional inputs ran 9,360 checks with 0 mismatches.
• Gap results are identical to the version before the optimization across 4,200 Berlin and Lord Howe cases.

New tests: a policy table in Cron.test.ts for next/prev/sequence (Berlin, daily, Casey, UTC, spring-forward gap), a prev gap regression table, and a TestClock test showing that Schedule.cron applies the policy for both the string and pre-parsed forms.

Closes #9902
Closes EFF-2905