Revert windows_arm64 build timeout increase (60 min -> 75 min) once arm64 build agents/builds are faster

> [!NOTE]
> This issue was drafted with GitHub Copilot.

## Context

windows_arm64 coreclr **build** jobs have been hitting the 60-minute ADO default timeout and getting canceled since ~end of May. Per @hoyosjs, the slowness comes from building the cross-arch tools needed to run crossgen (~22 -> 28 min), pushing total build time past 60 min (coinciding with the wasm build addition).

## Mitigation (#129553)

Added a 75-minute timeout **floor** for `windows_arm64` build jobs in `eng/pipelines/common/global-build-job.yml`. This is intentionally a crutch at the `global-build-job` layer rather than per-callsite (see review discussion on #129553).

## Why this issue

Tracking the revert: once arm64 build-agent throughput improves or the cross-tool build is sped up, restore `timeoutInMinutes: ${{ parameters.timeoutInMinutes }}` in `global-build-job.yml` so windows_arm64 returns to the 60-min default.

## Affected pipelines (empirical, public CI, last 35 days)

pgo, r2r, r2r-extra, crossgen2, crossgen2-outerloop, crossgen2-composite, crossgen2-gcstress, jitstress, jitstressregs, jitstress2-jitstressregs, jit-experimental, jitstress-isas-arm, jitstress-random, pgostress, ilasm, coreclr outerloop (ci.yml), interpreter, gc-standalone, gc-simulator, gcstress0x3-gcstress0xc, gcstress-extra.

The main `runtime` PR pipeline is **not** affected — its windows_arm64 builds already set 120-240 min.

Start in eng/pipelines/common/global-build-job.yml and review the windows_arm64 timeout floor introduced by #129553. Confirm that arm64 build-agent throughput or cross-tool build time has improved, then restore timeoutInMinutes: ${{ parameters.timeoutInMinutes }}. Done means windows_arm64 returns to the 60-minute default without affecting pipelines that set longer timeouts.

Written by the indexing model from the issue text.