Update pipeline status after individual job rerun

What does this MR do and why?

Fixes pipeline status not updating in Security Inventory after individual job reruns.

Previously, when a security scan job was rerun individually, the Security Inventory would continue to show the status of the original (failed/cancelled) job rather than the latest successful rerun. This happened because the Security::AnalyzersStatus::UpdateService was not filtering for the latest jobs when multiple versions of the same job existed due to retries.

This MR adds the .latest scope to the pipeline builds query, ensuring that only the most recent version of each job is considered when updating the analyzer status.

Closes #558762

Changelog: fixed EE: true

How to set up and validate locally

1. Create a pipeline with a security scan job (e.g., secret detection).
   You can use this example of .gitlab-ci.yml. It will pass if the current minute is odd and fail if the current minute is even:

image: alpine:latest

dast:
  script:
    - '[ $(($(date +%M) % 2)) -eq 1 ] && exit 1 || exit 0'
  artifacts:
    reports:
      dast: samples/dast.json

secrets:
  script:
    - 'sleep 20'
  artifacts:
    reports:
      secret_detection: samples/secret-detection.json

2. Rerun the individual job
3. Check the Security Inventory - the pipeline status should now reflect the actual pipeline status

Technical Details

• Root Cause: The service was processing all completed jobs for a pipeline, including retried ones, without filtering for the latest version
• Solution: Added .latest scope to only consider the most recent version of each job
• Impact: Security Inventory will now correctly show pipeline status based on the latest job results, not historical failed attempts

Testing

Added test coverage for job retry scenarios:

• Original job fails, retry succeeds
• Original job succeeds, retry fails
• Multiple retries with different outcomes
• Aggregated analyzer types with retries
• Normal operation without retries

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.