Resolve "Bad SQL in the migration of job artifact registries to a separate table"

What does this MR do?

Fixes a data integrity issue in a Geo tracking DB migration

Are there points in the code the reviewer needs to double check?

The migration wasd introduced for v10.7 which has only had RCs so far. GPRD has been bitten by this bug: gitlab-com/migration#308 (closed) but I believe we're fine to modify the migration inline as we don't expect customers to run RCs (or at least, we don't support them if they do and things break!)

Why was this MR needed?

Without this change, the data migrated to the new job_artifacts_registry table is junk. Worse yet, we remove the source data in file_registry so the entries are lost forever.

Mitigating this is the fact that the tracking DB is more-or-less second-order data - we can always regenerate it from scratch. The worst-case scenario when doing this for job_artifacts_registry is that some artifacts that should be removed from disk, will not be removed. So it's not a critical data loss issue, but it is fairly bad.

Screenshots (if relevant)

Does this MR meet the acceptance criteria?

• Changelog entry added, if necessary
• Tests added for this feature/bug
• Review
  • Has been reviewed by Backend
  • Has been reviewed by Database
• EE specific content should be in the top level /ee folder
• Conform by the merge request performance guides
• Conform by the style guides
• Squashed related commits together
• Internationalization required/considered
• If paid feature, have we considered GitLab.com plan and how it works for groups and is there a design for promoting it to users who aren't on the correct plan
• End-to-end tests pass (package-qa manual pipeline job)

What are the relevant issue numbers?

Closes #5646 (closed) and https://gitlab.com/gitlab-org/gitlab-ee/issues/5639