Google confirmed the cloud workstation image pull tries unauthenticated first so it doesn't leak credentials when they aren't needed.

So a possible correction on the Google Cloud Build behavior, the similar unauthenticated access before authenticated access behavior is when Google Computer Engine is pulling a docker image for a Google Cloud Workstation, not a build. In that scenario, trying unauthenticated first might make sense since you don't know if credentials (service account) are needed for that pull and making an unauthenticated request in that scenario might leak at least some authentication information.

The Google Cloud Build does not have the unauthenticated request first and works first time.
That particular scenario is a bit different than the Bitbucket pipeline scenario where you have the authentication information right there with the image to pull. It's not an implied authentication like it is with the Google Cloud service account situation. It's explicitly set on that image pull.
See attached screenshot of Docker-HeadManifest requests. First entry is the Google Cloud Build fetching base image for a nightly scheduled rebuild... no unauthenticated request. Second and third requests are from the Google Cloud Workstation launch, the first one fails because an unauthenticated request is attempted, similar to Bitbucket's current behavior, but I don't believe Bitbucket's behavior is justified while Google's workstation image pull behavior may be.
I put a Google ticket in to confirm that rationale on the behavior difference.

When testing service account authentication with Docker 27.1.1 build 6212585 with the service account token method at https://cloud.google.com/artifact-registry/docs/docker/authentication there was no extra unauthenticated calls, so Docker is using the authentication on all calls as expected and not making noisy failing calls as the pulls from Bitbucket are doing. If docker is what Bitbucket Pipelines are using, it seems something is causing initial unauthenticated calls. So version of docker may be a factor or a different tool like containerd is being used to pull the image and behaves differently.