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