Add `author_source` property to CI config internal events

What does this MR do and why?

Adds an author_source additional property to two existing internal events:

• commit_change_to_ciconfigfile (fires when CI config is modified on the default branch)
• create_ci_config_file (fires when CI config is created on any branch)

How author_source is determined

The value comes directly from the Duo-Workflow-Definition git trailer on the commit:

• If the trailer is present, its value is used as-is (e.g., ci_expert_agent/v1)
• If the trailer is absent or empty, the value is human

Currently, only the CI Expert Agent sets this trailer (Duo-Workflow-Definition: ci_expert_agent/v1). As more agents adopt the same trailer convention, their values will automatically flow through without any code changes. This also enables version-level granularity in analytics (e.g., distinguishing ci_expert_agent/v1 from ci_expert_agent/v2).

Why this matters

This enables analytics to answer:

Question	Query
How many CI config modifications are from agents vs humans?	commit_change_to_ciconfigfile GROUP BY author_source
How many CI configs were created by which agent?	create_ci_config_file WHERE author_source != 'human' GROUP BY author_source
Configs created by agent then modified by human?	Join create_ci_config_file with commit_change_to_ciconfigfile(author_source=human) on project

Technical note: trailer fetching

Commits loaded via commits_between use Gitaly's ListCommitsRequest, which does not populate trailers. To access trailers, ci_config_author_source re-fetches the commit via repository.commit(sha) (uses FindCommitRequest, which supports trailers). This only runs for the commits that touch the CI config file, so the extra Gitaly call is negligible.

Part of a series:

1. This MR: Add author_source property to CI config events (Snowplow counting)
2. Add ci_config_ai_generated boolean to ci_project_metrics table (DB persistence)
3. Enrich completed_pipeline_execution event with ai_generated property

Known limitation

If a user changes the project's CI config path setting, the tracking applies to whatever path is current at push time. Historical tracking does not follow path changes. This is acceptable for v1.

Relates to #596636 Part of #594029

How to set up and validate locally

1. Start the internal events monitor for both events:

   rails runner scripts/internal_events/monitor.rb commit_change_to_ciconfigfile

   In a separate terminal:

   rails runner scripts/internal_events/monitor.rb create_ci_config_file

2. Test human commit (config change):

   • Clone a project that already has a .gitlab-ci.yml file
   • Make a change to .gitlab-ci.yml and push to the default branch
   • Verify commit_change_to_ciconfigfile appears in the monitor with author_source: human

3. Test AI agent commit (config change):

   • Make a change to .gitlab-ci.yml with a commit message containing the trailer:

     Update CI config
     
     Duo-Workflow-Definition: ci_expert_agent/v1

   • Push to the default branch
   • Verify commit_change_to_ciconfigfile appears in the monitor with author_source: ci_expert_agent/v1

4. Test human commit (config creation):

   • Clone a project without a .gitlab-ci.yml file
   • Create a .gitlab-ci.yml file and push to any branch
   • Verify create_ci_config_file appears in the monitor with author_source: human

5. Test AI agent commit (config creation):

   • Create a .gitlab-ci.yml file with a commit message containing the Duo-Workflow-Definition: ci_expert_agent/v1 trailer
   • Push to any branch
   • Verify create_ci_config_file appears in the monitor with author_source: ci_expert_agent/v1

6. Verify author_source reflects the trailer value:

   • Push a commit with Duo-Workflow-Definition: some_other_agent/v1 modifying .gitlab-ci.yml
   • Verify the event fires with author_source: some_other_agent/v1 (not human)

7. Verify human is used when:

   • The commit has no Duo-Workflow-Definition trailer
   • The commit has a Duo-Workflow-Definition trailer with an empty value

MR acceptance checklist

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