Restrict credits date ranges to subscription period

What does this MR do and why?

The GitLab Credits dashboard offers date range presets that cannot work when the subscription started recently. Picking one of those presets leaves the dashboard blank with no explanation. This MR stops the UI from offering ranges that start before the subscription began.

The GraphQL resolver clamps the requested start date up to the subscription start date but leaves the end date alone. For a subscription starting 2026-08-03, "Last month" becomes startDate: "2026-08-03", endDate: "2026-07-31", and the resolver's own validation then raises end_date must be after or equal to start_date.

To fix that from the UI side, the subscription start date is now passed from the view layer into the Vue app. Presets that end before the subscription started are removed. Presets that merely begin before it are clamped to it. The custom date picker gets a minimum date so an earlier start cannot be chosen. "Custom" is always kept available, because if the subscription start is later than every preset, removing it too would leave nothing selectable. When no subscription start date is available, nothing changes.

This is the follow-up named in https://gitlab.com/gitlab-org/gitlab/-/issues/596646, which deferred the UI-side restriction until the subscription start date was available on the frontend.

The API-side question is left open on purpose. See the issue for details.

Screenshots or screen recordings

Before	After

How to set up and validate locally

1. Pick or create a group with a GitLab subscription, and note its path.

2. In rails console, set the subscription start date to a few days ago so that older presets become impossible:

   group = Group.find_by_full_path('your-group-path')
   group.gitlab_subscription.update!(start_date: 3.days.ago.to_date)

3. Visit the group's Usage Quotas page and open the GitLab Credits tab.

4. Open the date range filter. "Last month" should no longer be listed, because that whole period ends before the subscription started. "This month", "Last 7 days" and "Last 30 days" should still be listed and should load data rather than showing a blank dashboard.

5. Choose "Custom" and try to pick a start date before the subscription start date. The picker should not allow it.

6. To see the difference, check out master (or stash this branch's changes) and repeat steps 3 and 4. "Last month" is offered, and selecting it leaves the dashboard without data.

7. Optionally, set start_date back to a date well in the past and confirm every preset is offered again and the picker is unrestricted.

For the self-managed path, the value comes from License.billable_license&.starts_at and is rendered by the admin GitLab Credits dashboard view.

Changes

View and helper:

• ee/app/helpers/ee/groups/settings_helper.rb - usage_billing_dashboard_data now includes subscription_start_date: group.gitlab_subscription&.start_date&.iso8601.
• ee/app/views/admin/gitlab_credits_dashboard/index.html.haml - passes subscription_start_date: License.billable_license&.starts_at&.iso8601 for the self-managed case.

Frontend:

• New ee/app/assets/javascripts/usage_quotas/wallet_agnostic_credits_dashboard/shared/components/utils.js with availableDateRangeOptions(options, subscriptionStartDate) and initialDateRangeOption(option, subscriptionStartDate). Dates are compared as plain strings, since both sides are YYYY-MM-DD and that format sorts chronologically.
• .../wallet_agnostic_credits_dashboard/index/index.js - reads subscriptionStartDate from the element dataset and passes it through Vue provide.
• .../wallet_agnostic_credits_dashboard/index/components/app.vue - injects subscriptionStartDate, replaces the static options list with a computed dateRangeOptions, and passes a local-midnight Date as the custom range minimum.
• .../wallet_agnostic_credits_dashboard/shared/components/date_range_filter.vue - new optional customDateRangeMinDate prop, wired to the default-min-date prop GlDaterangePicker already supports.

Tests:

• New utils_spec.js, plus additions to the dashboard app spec, the date range filter spec, the group helper spec, and the admin view spec.

Testing

262 frontend tests pass. The new utils_spec.js has 13 cases, covering boundary conditions such as a subscription starting exactly on a preset boundary, and a check that the input options are not mutated. The dashboard app spec gains 8 cases and the date range filter spec gains 2. Ruby specs were added for the group helper and the admin view, each covering both the present and absent subscription cases.

The new customDateRangeMinDate prop is optional, so the sibling user_credits_dashboard app that reuses DateRangeFilter is unaffected. It does not receive a subscription start date yet, so it still has the same gap. That needs a follow-up for parity.

References

Related to #623318 (closed)