Add created_by_duo marker to MergeRequests analytics

What does this MR do and why?

Adds a created_by_duo flag to the ClickHouse merge request analytics data, so it's possible to tell which MRs were created through a GitLab Duo Agent Platform (DAP) session. This is needed for the DAP Impact Dashboard, which wants to show an "Agent MR acceptance rate": the share of Duo-created MRs that end up merged. The aggregation engine also gains a general acceptanceRate metric and a createdByDuo dimension/filter, exposed over GraphQL.

Changes:

• ClickHouse schema: new created_by_duo column on the merge_requests analytics table, sourced from the siphon_duo_workflows_workflow_merge_requests link table (only created links, deduplicated, soft-deleted rows excluded).
• Materialized view: merge_requests_mv is updated in place (ALTER TABLE ... MODIFY QUERY) so it keeps populating the flag on new and re-replicated MR rows, with no gap in inserts. A projection on the link table keyed by merge_request_id keeps the lookup efficient.
• Backfill: a post-deploy migration sets created_by_duo = true for existing MRs that already have a created link. It runs as an async mutation and is idempotent.
• Aggregation engine / GraphQL: new createdByDuo dimension and filter, and a new acceptanceRate metric, available through analytics.mergeRequests.

Notes:

• The flag is set when an MR row is created or re-replicated, so it lands on creation or the next update; the backfill covers MRs that already existed.
• Only MRs created through a DAP session after the created link was introduced will carry the flag.

References

• Issue: https://gitlab.com/gitlab-org/gitlab/-/issues/608191
• DAP Impact Dashboard epic: https://gitlab.com/groups/gitlab-org/-/work_items/23225
• Depends on #616992 (Siphon replication of the link table)

Screenshots or screen recordings

Backend and ClickHouse schema changes only, no UI changes.

How to set up and validate locally

1. Run ClickHouse migrations: bundle exec rake gitlab:clickhouse:migrate
2. Insert a created link row for an existing MR into siphon_duo_workflows_workflow_merge_requests (link_type = 1) via the ClickHouse client, or create an MR through a Duo Agent Platform session.
3. Re-insert / re-replicate the MR row into siphon_merge_requests (or run the backfill migration) so the materialized view picks it up, then check SELECT id, created_by_duo FROM merge_requests FINAL WHERE id = <mr_id> returns true.
4. Query GraphQL, e.g.:

query {
  group(fullPath: "<group-path>") {
    analytics {
      mergeRequests(createdByDuo: [true]) {
        aggregated {
          nodes {
            dimensions { createdByDuo }
            acceptanceRate
            throughputCount
          }
        }
      }
    }
  }
}

5. Run specs:

bundle exec rspec ee/spec/models/analytics/aggregation_engines/merge_requests_spec.rb \
  ee/spec/requests/api/graphql/analytics/merge_requests_spec.rb \
  spec/db/click_house/post_migrate/20260910104402_backfill_created_by_duo_on_merge_requests_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.

Related to #608191