Add audit events for merge requests merged through another merge request or a push

What does this MR do and why?

Adds two audit event types for merge requests that GitLab marks as merged because something else included their changes:

• merge_request_merged_through_merge_request: another merge request was merged. Details: source_merge_request_id, source_merge_request_iid, source_project_id.
• merge_request_merged_by_push: a commit was pushed to the target branch. Details: source_commit_sha.

Today these merges only produce merge_request_merged, which reports zero approvals and no reason, so compliance tooling flags them as unapproved. The existing event is unchanged; the new one is recorded alongside it, and streaming destinations can filter on the new types.

Second of three MRs for #512551. Stacked on !260938 (merged), which adds MergeRequest#merge_source.

Details

• MergeAuditEventService runs from ProcessMergeAuditEventWorker on MergeRequests::MergedEvent. PostMergeService records the merged state event before publishing that event, so merge_source is available when the worker runs.
• Errors from the new event are tracked with Gitlab::ErrorTracking and not raised. A raise would retry the worker and record merge_request_merged a second time.
• The source is only as accurate as the merged state event. !260499 fixes a race that sometimes records a pushed commit for merge requests merged through another merge request.
• No feature flag: the change only adds events, and the error handling keeps it from affecting the existing one.
• Verified: ee/spec/services/merge_requests/merge_audit_event_service_spec.rb and ee/spec/workers/merge_requests/process_merge_audit_event_worker_spec.rb (13 examples, 0 failures), rubocop clean, audit event types docs regenerated.

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.