ical-recurrence: test that the limit only ever reveals more occurrences The limit is an implementation detail of this library, not anything a recurrence rule says, so raising it must only ever reveal occurrences beyond the old one. It must never change the occurrences already below it. This is the general form of the BYSETPOS bugs: monthly, weekly and yearly each had a limit narrowing a candidate set that a rule part then selected from, so raising the limit moved the instance BYSETPOS picked. This passes, so there is nothing red here and no accompanying change; it is a guard against that whole class coming back rather than a fix. It is a guard that works. Reintroducing just the monthly leak, the one line `guard (d <= limit)` back inside the list filterSetPos numbers, and running this alone fails at case 35 on a generated FREQ=MONTHLY rule with BYSETPOS. It was checked that way rather than assumed to be load bearing. SECONDLY, MINUTELY and HOURLY are excluded. The limit has day granularity, so the narrowest window this can ask for still spans 86400 seconds, and generating that many occurrences twice per case is too slow to be worth it. They step through the same code as the rest. Verified out of band to 1000 cases. It runs at the default 100 in CI, because 3000 takes longer than sydtest's per-test timeout.