LF-5300: Extend DateRangeSelector with filtered options and dynamic year entries

[litefarm-pr-bot]

Description

The shared DateRangeSelector currently hard-codes its dropdown contents to a fixed list of nine static options. Any consumer that wants a different subset, or that needs to inject ranges derived from data (for example, a list of calendar years for which transactions exist), has no way to do so without either forking the component or hiding rows in CSS. This change adds two opt-in props that close that gap without affecting any existing call site.

DateRangeInput now accepts an allowedOptions prop (an explicit allowlist of built-in DateRangeOptions, rendered in the order given) and a dynamicOptions prop (caller-supplied entries with pre-baked startDate/endDate, rendered between the static options and the CUSTOM row). When both are omitted, the dropdown renders exactly the same nine entries it did before, so no other consumer needs to change. A new LAST_12_MONTHS enum value and matching getLast12MonthsDateRange() method on DateRange are added at the same time — intentionally excluded from the default option set, so they only appear when a caller explicitly opts in via allowedOptions. The option-building and dynamic-value lookup logic was lifted into a helpers.ts module that can be unit-tested without rendering react-select, and useDateRange was hardened so that a persisted dynamic value (an arbitrary string that is not a known enum value) does not cause getDates(option) to throw when the hook recomputes on mount.

The convention this PR establishes is: when a shared component needs to support per-consumer variation, prefer additive opt-in props with backward-compatible defaults over a forked component. Adding new entries to a shared enum is fine, but only wire them into the default option list when every existing consumer is intended to see them — otherwise gate visibility behind the explicit allowedOptions allowlist so the default behaviour stays frozen.

Jira link: https://lite-farm.atlassian.net/browse/LF-5300

Type of change

• New feature (non-breaking change which adds functionality)
• Bug fix (non-breaking change which fixes an issue)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• This change requires a documentation update

How Has This Been Tested?

• Passes test case
• UI components visually reviewed on desktop view
• UI components visually reviewed on mobile view
• Other (please explain): pnpm exec vitest run src/tests/dateRange.test.js src/tests/dateRangeSelectorHelpers.test.js — 204 tests pass (192 existing DateRange cases plus three new LAST_12_MONTHS expectations, plus 12 new helpers tests covering allowedOptions filtering, dynamicOptions insertion before CUSTOM, dynamic-option label pass-through, isStaticDateRangeOption, and findDynamicDateRange). No local frontend was running; visual review of the rendered dropdown was not performed and should be confirmed when the dynamic-options consumer lands.

Checklist:

• I have commented my code, particularly in hard-to-understand areas
• My changes generate no new warnings
• I have added tests that prove my fix is effective or that my feature works
• New and existing unit tests pass locally with my changes
• The precommit and linting ran successfully
• I have added or updated language tags for text that's part of the UI
• I have ordered translation keys alphabetically (optional: run pnpm i18n to help with this)
• I have added the GNU General Public License to all new files