Add ecr:BatchGetImage permission to helm-publish workflow

[yerzhan7]

Issue #, if available: N/A

Description of changes:

The verify-helm-images.sh script uses crane digest to verify sidecar
images (livenessprobe, node-driver-registrar) in the EKS ECR repo.
crane resolves manifests via HEAD/GET requests which require
ecr:BatchGetImage, but the inline session policy only granted
ecr:GetAuthorizationToken for docker login. Add ecr:BatchGetImage
scoped to the EKS ECR repository. Related to #741

Manual testing:

crane digest 602401143452.dkr.ecr.us-east-1.amazonaws.com/eks/livenessprobe:v2.18.0-eksbuild.3
sha256:8e307f4e5820108231c0d887f426e5437ccff1683ac3dd9656c96a078fb53d3f

Previous error from local reproduction:

crane digest 602401143452.dkr.ecr.us-east-1.amazonaws.com/eks/livenessprobe:v2.18.0-eksbuild.3
2026/03/25 17:30:50 HEAD request failed, falling back on GET: HEAD https://602401143452.dkr.ecr.us-east-1.amazonaws.com/v2/eks/livenessprobe/manifests/v2.18.0-eksbuild.3: unexpected status code 403 Forbidden (HEAD responses have no body, use GET for details)

Error: GET https://602401143452.dkr.ecr.us-east-1.amazonaws.com/v2/eks/livenessprobe/manifests/v2.18.0-eksbuild.3: DENIED: User: arn:aws:sts::XXX:assumed-role/XXX is not authorized to perform: ecr:BatchGetImage on resource: arn:aws:ecr:us-east-1:602401143452:repository/eks/livenessprobe because no session policy allows the ecr:BatchGetImage action

Helm failing workflow: https://github.com/awslabs/mountpoint-s3-csi-driver/actions/runs/23543258639/job/68572809411

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

[jet-tong]

np: could add comment on why we need batchgetimage here appending to old comment.

It did successfully check livenessprobe:v2.18.0-eksbuild.1 in helm publish #19, do you know why it requires this BatchGetImage now? (could it be .3 vs .1?)

[yerzhan7]

I suspect this introduced the bug? #741

Thanks for reviewing!

[jet-tong]

No that was part of the bug fix that allowed helm publish 19 to succeed in v2.4.1 release (which was failing before), perhaps something else was the cause?

[yerzhan7]

Yeah, you are right because the workflow still fails after this.