Add human actor guard to GitAuditEvent before re-enabling feature flag
## Context The `log_git_streaming_audit_events` feature flag was globally enabled but had to be reverted due to 404/401 errors caused by non-human actors (deploy tokens, deploy keys) that the audit event endpoint couldn't resolve. The full fix for deploy tokens (#562516) and deploy keys (gitlab-org/gitlab-shell#822) requires multiple MRs across Rails, Workhorse, and gitlab-shell. To unblock the feature flag rollout for human actors while those fixes are in progress, we should add a guard to only audit human user git operations. ## Proposal Add a `user.human?` check to `GitAuditEvent#enabled?`: `user.human?` filters out: * Deploy tokens (not a `User` at all) * Ghost users (deploy keys without an owner fall back to a ghost user, which would cause a 404 because the ghost user has no project access) * Other non-human actors (bots, service accounts) Once the proper fixes land in gitlab-org/gitlab-shell#822 and #562516, we can remove the `user.human?` guard and support all identity types. ## References * Parent issue: #562516 * SSH fix: gitlab-org/gitlab-shell#822 * Feature flag: `log_git_streaming_audit_events` * Discussion: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/223145#note_3106072312
issue