Fix ci pipeline reference when pushing duplicate NuGet package

What does this MR do and why?

Pushing a NuGet package from a CI pipeline doesn't always link to the CI pipeline properly.

• If the package doesn't already exist, everything works as expected
• If the package already exists, new package files are appended but the link to the CI pipeline is lost.

When a package already exists, the background job will locate the existing package and move the package files from the temporary package to the existing package.

The problem is that the build info (which is the object that links between a package and a CI pipeline) is not moved to the existing package.

The temporary package is then destroyed = the link with a CI pipeline is completely lost.

In this MR, I move the build info from the package to be destroyed (the temp package) to the existing package.

Screenshots or screen recordings

Screenshots are required for UI changes, and strongly recommended for all other merge requests.

Before	After

How to set up and validate locally

1. Create a blank project in your GDK and publish a dummy NuGet package using CI/CD by creating the following .gitlab-ci.yml file in the new project:

image: mcr.microsoft.com/dotnet/sdk:7.0

stages:
  - deploy

before_script:
  - apt-get update 
  - apt-get install -y nuget
  - dotnet nuget add source "$CI_API_V4_URL/projects/$CI_PROJECT_ID/packages/nuget/index.json" --name gitlab --username gitlab-ci-token --password $CI_JOB_TOKEN --store-password-in-clear-text

deploy:
  stage: deploy
  script:
    - nuget spec 
    - nuget pack
    - dotnet nuget push *.nupkg -s gitlab
  only:
    - main

2. After the pipeline succeeded, navigate to the Package Registry page in the project, you should see the package published and the commit is referenced.
3. Edit the .gitlab-ci.yml file by adding any new line to just trigger a new CI/CD pipeline when committing the changes. For example, you can put echo 'testing' in the script of the deploy stage.
4. After the 2nd pipeline is green, refresh the Package Registry page and you should find the new commit is referenced.
5. On master, if you repeated the steps above, the commit wouldn't be updated on the Package Registry page.

MR acceptance checklist

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

• I have evaluated the MR acceptance checklist for this MR.

Related to #348800 (closed)