Backport of Ensure LFS imports work correctly with nil revisions

What does this MR do and why?

Adds a nil check for params[:updated_revisions] in LfsListService to ensure LFS imports work correctly.

Why was this MR needed?

The mirroring_lfs_optimization optimisation was being incorrectly applied to import scenarios where params[:updated_revisions] is nil. This caused the condition nil != ['--all'] to evaluate to true, triggering the optimisation path which calls new_pointers with nil revisions, resulting in no LFS files being discovered during imports.

How does this MR fix the problem?

Adds params[:updated_revisions].present? check to the condition, ensuring:

For imports (where updated_revisions is not passed. Only project is passed. ):

• params[:updated_revisions].present? returns false.
• Falls back to all_pointers to scan entire repository.

For mirroring (where updated_revisions has data):

• params[:updated_revisions].present? returns true.
• Uses optimisation to scan only new commits.

What happens when mirroring has no changes? Does this fix force mirroring to fall back to all_pointers to scan entire repository?

No, when there are no changes, UpdateMirrorService returns early and doesn't call LfsImportService. So, Gitlab wouldn't process mirroring LFS objects at all.

MR acceptance checklist

This checklist encourages us to confirm any changes have been analyzed to reduce risks in quality, performance, reliability, security, and maintainability.

• This MR is backporting a bug fix, documentation update, or spec fix, previously merged in the default branch.
• The MR that fixed the bug on the default branch has been deployed to GitLab.com (not applicable for documentation or spec changes).
• The MR title is descriptive (e.g. "Backport of 'title of default branch MR'"). This is important, since the title will be copied to the patch blog post.
• Required labels have been applied to this merge request
  • severity label and bug subtype labels (if applicable)
  • If this MR fixes a bug that affects customers, the customer label has been applied.
• This MR has been approved by a maintainer (only one approval is required).
• Ensure the e2e:test-on-omnibus-ee job has succeeded, or if it has failed, investigate the failures. If you determine the failures are unrelated, you may proceed. If you need assistance investigating, reach out to a Software Engineer in Test in #s_developer_experience.

Note to the merge request author and maintainer

If you have questions about the patch release process, please:

• Refer to the patch release runbook for engineers and maintainers for guidance.
• Ask questions on the #releases Slack channel (internal only).
• Once the backport has been merged, the commit changes will be automatically deployed to a release environment that can be used for manual validation. See after merging runbook for details.