Make origin-anchored Xd granularity the default for all aggregation engines

What does this MR do and why?

DAP Impact dashboards need to compare rolling periods, like the last 30 days versus the previous 30 days, for any metric. Time bucketing previously only understood calendar periods (daily, weekly, monthly), so a rolling comparison meant two separate requests stitched together, which is slower and easier to get wrong.

This MR makes fixed-day, origin-anchored granularity a built-in default for every aggregation engine instead of something each engine has to opt into. Date bucket dimensions now accept daily, weekly, monthly, or a fixed number of days such as 30d (from 1d to 399d), plus an optional origin timestamp. With a fixed-day granularity and an origin, buckets start at that origin and repeat every N days, so a single request returns the previous and current period side by side. Combining origin with a calendar granularity is rejected as invalid, and calendar granularities behave exactly as before.

Notes for reviewers:

• This surfaces in GraphQL as granularity and origin arguments on the date dimension fields of all aggregation response types (AgentPlatformSessions, Contributions, Deployments, DuoWorkflows, MergeRequests, Pipelines, CodeSuggestions, AiUsageEvents). The GraphQL reference docs and introspection result are regenerated.
• Because the dimension now has two default parameters, internal result column aliases include the parameter name (for example created_at_monthly becomes created_at_granularity_monthly). This accounts for most of the spec churn and has no effect on the GraphQL API, since clients choose their own field aliases.

Related to #609138

References

• Issue: https://gitlab.com/gitlab-org/gitlab/-/issues/609138
• Epic: https://gitlab.com/groups/gitlab-org/-/work_items/23225

Screenshots or screen recordings

Not applicable: backend and GraphQL API change only.

How to set up and validate locally

1. Ensure ClickHouse is running in GDK.

2. Enable the feature flag in a Rails console: Feature.enable(:dap_impact_v1).

3. Make sure there is some Duo Workflow / agent session data for a group you can query.

4. Run the following GraphQL query against that group:

   query {
     group(fullPath: "gitlab-org") {
       analytics {
         duoWorkflows {
           aggregated(orderBy: [{ identifier: "createdAt", direction: ASC, parameters: { granularity: "30d", origin: "2026-01-01T00:00:00Z" } }]) {
             nodes {
               dimensions { period: createdAt(granularity: "30d", origin: "2026-01-01T00:00:00Z") }
               totalCount
               usersCount
             }
           }
         }
       }
     }
   }

   Expect one node per 30-day window starting at the origin, with the previous and current window both present in the same response.

5. Confirm that combining granularity: "monthly" with an origin returns a validation error.

6. Confirm that plain granularity: "monthly" (no origin) still works as before.

7. Run the relevant specs:

   bin/rspec spec/lib/gitlab/database/aggregation/click_house/date_bucket_dimension_spec.rb ee/spec/requests/api/graphql/analytics/duo_workflows_spec.rb

MR acceptance checklist

Evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.

🤖 Generated with Claude Code