Record SSH certificate provenance in Git audit events

What does this MR do and why?

Addresses "Gap 1" in https://gitlab.com/gitlab-org/gitlab/-/work_items/611349.

Shell half MR: gitlab-shell!1580 (merged)

Streamed Git audit events now record which SSH certificate authority (CA) signed the certificate used for a Git operation. Operators can then find all operations authenticated through a particular CA.

The Git audit callback (POST /internal/shellhorse/git_audit_event) accepts three new optional fields. When they are present, they are added to the existing repository_git_operation event under details.custom_message:

Field	Meaning
ca_fingerprint	SHA256 fingerprint of the signing CA, including the SHA256: prefix
certificate_identity	The certificate's KeyId, exactly as it appears in the certificate. It can differ from the resolved GitLab user.
certificate_trust_source	Where the CA is trusted: file, group, or instance. Used to distinguish instance versus group and file-based certificate trust

I've prepared a follow-up documentation entry to doc/user/compliance/audit_event_schema.md, which I'll push once I'm sure which milestone the corresponding Shell change will land in.

References

Contributes to https://gitlab.com/gitlab-org/gitlab/-/work_items/611349.

Screenshots or screen recordings

Not applicable. This change has no UI.

How to set up and validate locally

1. In a Rails console, find a user and a project the user can access, and generate a GitLab Shell request token:

   user = User.find_by_username('root')
   project = Project.first
   token = JSONWebToken::HMACToken.new(Gitlab::Shell.secret_token).tap { |t| t.issuer = Gitlab::Shell::JWT_ISSUER }.encoded
   puts token, user.username, "project-#{project.id}"

2. Call the audit callback with certificate metadata:

   curl --request POST "http://gdk.test:3000/api/v4/internal/shellhorse/git_audit_event" \
     --header "Gitlab-Shell-Api-Request: <token>" \
     --data "action=git-upload-pack&protocol=ssh&changes=_any&gl_repository=<gl_repository>&username=<username>" \
     --data "ca_fingerprint=SHA256:example&certificate_identity=Sidney.Jones@example.com&certificate_trust_source=group"

3. Confirm that the response message includes the three fields, unchanged.

4. Repeat the request without the certificate fields. Confirm that the response matches the existing behavior.

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.