Add duo_related label to member_destroyed audit events

What does this MR do and why?

Several generic audit events fire as side effects of DAP (Duo Agent Platform) operations but carry no DAP-specific labeling, making SIEM correlation difficult without filtering on service account username patterns (duo-*, ai-*, etc).

This MR addresses the member_destroyed case from #593024. When a DAP/Duo service account membership is destroyed (for example on flow disable or duo_features_enabled=false), the member_destroyed audit event now carries a duo_related: true flag inside additional_details. SIEM rules can then filter on event detail instead of brittle username patterns.

This is the backward-compatible approach (Implementation 1): the event type stays member_destroyed, so all existing SIEM rules continue to work unchanged. Only an additional detail key is added when the removed member is a DAP service account.

Implementation notes

• Detection reuses User#ai_service_account? (service_account? && composite_identity_enforced?), which is how DAP service accounts are already identified across the codebase. No new predicate or username matching is introduced.
• The predicate also matches Amazon Q service accounts: Ai::AmazonQ::CreateService creates them with composite_identity_enforced: true, so removing an Amazon Q membership gets tagged duo_related: true as well. This is intentional, GitLab Duo with Amazon Q falls under the same Duo umbrella for SIEM purposes.
• The flag is only set when the member is a DAP service account, so non-DAP member_destroyed events are completely unchanged.
• Change is scoped to EE::Members::DestroyService#log_audit_event.

Related

• Issue: #593024
• Epic: &20231
• Documentation: !245745 (merged)

Screenshots or screen recordings

N/A (audit event detail change)

How to set up and validate locally

1. Enable a DAP/Duo flow that provisions a Duo service account into a group/project.
2. Disable the flow (or set duo_features_enabled=false) so the service account membership is destroyed.
3. Inspect the resulting member_destroyed audit event details and confirm duo_related: true is present.
4. Remove a regular member and confirm the member_destroyed event does not contain duo_related.

MR acceptance checklist

• Tests added for the new behavior (ee/spec/services/ee/members/destroy_service_spec.rb).
• Confirm the DAP service-account predicate with the assignee before un-drafting.