Add audit events for Secret Push Protection fail-open scenarios

Problem

When Secret Push Protection cannot complete a scan, it fails open (i.e. the push is allowed through unscanned) but produces no customer-visible audit trail. Only internal events are recorded, which security/compliance teams cannot see or forward to their own external monitoring and alerting tools.

This was raised in a customer call as a trust blocker: teams can't monitor when SPP silently stops protecting them.

Fail-open paths

Location	Trigger	Current telemetry
SecretsCheck#handle_ruleset_error	Ruleset parse/compile error	internal event only
SecretsCheck#handle_too_many_changed_paths_error	Diff exceeds changed-paths limit	internal event only
SecretsCheck#handle_too_many_lines_error	Diff exceeds line-count limit	internal event only
SecretsCheck#handle_standard_error	Unexpected error (e.g. GRPC/SDS unavailable)	internal event only
ResponseHandler#format_response SCAN_TIMEOUT	Scanning process timed out	none
ResponseHandler#format_response INPUT_ERROR	Invalid input to scan	none

Proposal

• Add one audit event per failure type (mirrors existing internal event granularity).
• Create the audit events via Gitlab::Audit::Auditor.audit.
• Make use of should_log_audit_events? method.
• Follow the existing pattern in AuditLogger#log_skip_secret_push_protection.

New methods in AuditLogger:

• log_spp_ruleset_error
• log_spp_too_many_changed_paths
• log_spp_too_many_lines
• log_spp_generic_scan_error (generic/standard error)
• log_spp_scan_timeout
• log_spp_invalid_input

Each wired into its corresponding handler alongside the existing track_spp_* internal event call.

In addition, we need to:

• Add new config/audit_events/types/*.yml definitions for each event name.
• Update secret push protection documentation.
• Update audit events documentation in doc/user/compliance/audit_event_types.md.
• Update specs in ee/spec/lib/gitlab/checks/secret_push_protection/audit_logger_spec.rb.