smart_date_recur cron re-expansion ignores the field's month_limit, always uses the 12-month default

Problem/Motivation

The field-level recurrence setting third_party_settings.smart_date_recur.month_limit is not honored by the cron re-expansion path. smart_date_recur_cron selects every rule whose limit column is NULL (open-ended) and re-extends it via SmartDateRule::getNewInstances(), which resolves its window through getMonthsLimit($rule) — passing the rule entity, not the field definition. SmartDateRule exposes neither getThirdPartySetting() nor getSetting() for the field's recurrence config, so the lookup falls through to the hard-coded 12-month default and the field's month_limit is silently ignored.

Impact: a field configured with month_limit: 3 still gets its open-ended rules expanded to 12 months on the next cron run. Observed on 4.2.8: one cron run grew each weekly series 14 → 53 stored deltas. On a Views/FullCalendar render that serializes every stored occurrence, that pushed the page past PHP's execution/memory limits. The setting meant to cap this is bypassed.

Steps to reproduce

1. A Smart Date field with smart_date_recur enabled and month_limit set to a value other than 12 (e.g. 3).
2. Create a recurring event with an open-ended rule (no COUNT/UNTIL, so limit is stored NULL).
3. Run cron.
4. Inspect the stored instances — they extend ~12 months out, not month_limit months. The field setting had no effect.

Proposed resolution

Resolve month_limit from the field definition of the rule's field_name/entity_type/bundle (the rule entity already stores those) before falling back to the 12-month default in getMonthsLimit().

Remaining tasks

• Confirm the resolution path and add a test covering a non-default month_limit on an open-ended rule after cron.

Workaround

Bake an UNTIL at the desired horizon into imported/created rules so limit is never NULL and cron's isNull('limit') query never selects them. Hand-authored open-ended UI rules remain exposed until fixed upstream.