fix(ci): align UploadDependenciesCN test-repo S3 key with build_id

[fedeghiglio]

Description of the issue

The China (cn-north-1) EC2 integration tests were failing on every al2023
test case. The EC2LinuxCN terraform downloads a pre-cloned copy of the test
repo as a tarball from S3, at:

s3://<cn-bucket>/integration-test/cloudwatch-agent-test-repo/<cwa_github_sha>.tar.gz

where cwa_github_sha is set from the workflow's build_id. The only job that
produces that tarball, UploadDependenciesCN, was uploading it keyed by
${{ github.sha }} instead of ${{ inputs.build_id }}.

When build_id and the commit SHA differ (for example, when build_id is a
release-candidate build number rather than a commit SHA), the CN download misses
the tarball. The download step then falls back to cloning the test repo directly
from github.com — which is unreachable from inside the China partition — so the
test dependencies never land on the instance. This cascades to
install_agent.go: no such file or directory and fails every CN al2023 test.

Description of changes

Change the github_sha input of UploadDependenciesCN from ${{ github.sha }}
to ${{ inputs.build_id }}, so the upload key matches the key the CN download
uses. This aligns the producer with StartLocalStackCN, StopLocalStackCN, and
the other CN/ITAR consumers, all of which already reference inputs.build_id.

       region: cn-north-1
       test_repo_name: ${{ needs.OutputEnvVariables.outputs.CWA_GITHUB_TEST_REPO_NAME }}
       test_repo_branch: ${{ needs.OutputEnvVariables.outputs.CWA_GITHUB_TEST_REPO_BRANCH }}
-      github_sha: ${{github.sha}}
+      github_sha: ${{ inputs.build_id }}
       s3_integration_bucket: ${{ vars.S3_INTEGRATION_BUCKET_CN }}
       terraform_assume_role: ${{ vars.TERRAFORM_AWS_ASSUME_ROLE_CN }}

One-line change, no behavior change outside the CN artifact upload key.

License

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

Tests

Ran the full Test Artifacts workflow from this branch:
https://github.com/aws/amazon-cloudwatch-agent/actions/runs/30446999400

All China jobs passed — the tarball is now found and no github.com clone
fallback occurs:

• UploadDependenciesCN — success
• StartLocalStackCN — success
• EC2LinuxCN — all 13 al2023 test cases pass (cloudwatchlogs, xray,
  otlp, metric_dimension, metric_value_benchmark, restart,
  run_as_user, ssm_document, ca_bundle, collection_interval,
  entity_metrics_benchmark, feature_linux_journald_logs,
  log_state_journald)
• StopLocalStackCN — success

For comparison, before this change the same 13 EC2LinuxCN cases failed 13/13.

Note: the overall workflow run is marked failed due to unrelated test failures
on other platforms (GPU/EFA capacity on some EKS jobs, a TestDbi assertion,
and a few known-flaky SELinux/Windows cases). None are in the CN path and none
are affected by this change.