Fix flaky tests with IDs that do not exist in the DB

What does this MR do and why?

• Resolves a potential source of test flakiness that was causing intermittent failures in the Gitlab::Cleanup::RemoteArtifacts spec.

  The test was using hardcoded job_id: 1 and artifact_id: 2 in the untracked_valid_file_path, which could coincidentally match real database records. When this happened, the file would be considered "tracked" instead of "untracked" as expected. (The code errs on the side of "tracked" to ensure it doesn't delete legitimate files.)

• Resolves another potential source of test flakiness (it was probably just lucky because the hardcoded ID was 123, much bigger than 1 or 2).

How to set up and validate locally

1. Run the test multiple times to ensure this MR didn't break it:

   bundle exec rspec spec/lib/gitlab/cleanup/remote_artifacts_spec.rb

I didn't see the flaky failure locally so this doesn't necessarily prove that the flakiness is fixed, it just proves that I didn't make things significantly worse. But the issues will reopen if this didn't fix them.

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.

References

Closes https://gitlab.com/gitlab-org/quality/test-failure-issues/-/issues/2419

Closes https://gitlab.com/gitlab-org/quality/test-failure-issues/-/issues/2418

Additional context

This test has been failing intermittently with 77 flakiness reports. The root cause was identified as hardcoded IDs that could coincidentally match real database records, making the test dependent on database state rather than being deterministic.

The fix uses the existing non_existing_record_id helper method to ensure the test always uses IDs that don't exist in the database.