Output message when SPP throwns an exception

What does this MR do and why?

This MR improves the user experience when Secret Push Protection (SPP) encounters unexpected errors during scanning.

Problem: Currently, when SPP fails due to an unexpected error (e.g., a GRPC request to Gitaly times out), the error bubbles up and blocks the push. This creates a poor user experience where legitimate pushes are rejected due to SPP infrastructure issues rather than actual security concerns.

Solution: When SPP encounters a StandardError during the scanning process (excluding Gitlab::GitAccess::ForbiddenError which should still block), we now:

1. Catch the error and accept the push (fail-open behavior)
2. Queue a warning message in Redis that will be displayed to the user after the push completes
3. Show the message: "Secret Push Protection encountered an internal error and could not scan this push. The push has been accepted."

This provides a better user experience by:

• Not blocking legitimate pushes due to SPP infrastructure issues
• Providing transparency to users about what happened
• Letting users know their push was not scanned for secrets

Technical implementation:

• Created Gitlab::Checks::SecretPushProtection::PostPushWarning class (similar to ContainerMoved and ProjectCreated)
• Added rescue clause in SecretsCheck#run_validation! to catch StandardError and queue the warning
• Integrated warning display into PostReceiveService#add_user_repository_messages
• Added comprehensive test coverage for the new warning behavior

References

SPP errors should never cause git push to fail (#569064) • Craig Smith • 18.6

Screenshots or screen recordings

Before	After

How to set up and validate locally

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.