Bundle native arm64 helper binary in windows-servercore-ltsc2025-arm64 image

What does this MR do?

Switches the windows-servercore-ltsc2025-arm64 helper image from bundling the amd64 gitlab-runner-helper.exe (which ran under Windows emulation) to bundling the native arm64 gitlab-runner-helper.exe produced by MR 2 (#39416 (closed), !6697 (merged)).

Two small changes, ~3 lines net across 2 files:

• dockerfiles/runner-helper/docker-bake.hcl: removes the TARGETARCH = "amd64" override (and its accompanying comment) that was forcing every windows matrix entry — including the arm64 one — to pull the amd64 binary. Each entry now resolves TARGETARCH from item.arch like the rest of the bake file.
• scripts/pusher/helper-images.json: updates the windows-servercore-ltsc2025-arm64 mapping from x86_64-binary-arm64-platform-%-servercore24H2 to the native arm64-%-servercore24H2, mirroring alpine3.21-arm64, ubuntu-arm64, and concrete-arm64.

This is MR 3 of the 5-MR plan for full Windows ARM64 support in the docker-windows executor (parent: #39182 (closed)).

Why was this MR needed?

!6033 (merged) shipped the windows-servercore-ltsc2025-arm64 helper image as a deliberate, documented workaround: it bundled the amd64 helper binary running under Windows ARM64 emulation, because no native arm64 gitlab-runner-helper.exe existed yet. That workaround left two artefacts in the tree (the TARGETARCH override and the x86_64-binary-arm64-platform-... pusher entry) that needed to be removed once a native arm64 helper binary became available.

With MR 2 (#39416 (closed) / !6697 (merged)) producing that native binary, this MR cuts the existing arm64 helper image over to it. The user-visible win: customers already on the arm64 helper image (via !6033 (merged)) start running the helper natively instead of under emulation — lower CPU, faster job startup — with no config change on their side. It is also a prerequisite for MR 4 (nanoserver 2025 arm64), since nanoserver does not support amd64 emulation.

What's the best way to test this MR?

1. Wait for the prebuilt helper images windows 2025 arm64 CI job to build and publish the image; confirm artifact upload stays under the per-job size limit (the per-arch split from !6033 (merged) is preserved here).

2. Pull the resulting windows-servercore-ltsc2025-arm64 image and inspect the bundled gitlab-runner-helper.exe — it must be a PE32+ ARM64 binary, not amd64. For example:

   docker create --name h <image>
   docker cp h:"/Program Files/gitlab-runner-helper/gitlab-runner-helper.exe" .
   file gitlab-runner-helper.exe   # expect: PE32+ ... Aarch64

3. Run a docker-windows job using this image on a Windows ARM64 host (per the test recipe from !6033 (merged)) and confirm it completes successfully and no longer pays the amd64-emulation cost.

4. Confirm no behaviour change for the existing windows-servercore-ltsc2025-x86_64 image (it should still ship the amd64 binary).

What are the relevant issue numbers?

• Closes #39417 (closed)
• Parent issue: #39182 (closed)
• Depends on: #39416 (closed) / !6697 (merged) (must merge first)
• Previous MR in the series: !6033 (merged)
• Related (main gitlab-runner.exe arm64 build, already merged): !6495 (merged)
• Followed by: MR 4 (nanoserver 2025 arm64/amd64), MR 5 (host arch detection + auto-selection of the arm64 helper image)