gcs-endpoint: reported fallback to VM metadata identity when GOOGLE_APPLICATION_CREDENTIALS cannot be parsed (uv 0.12.23)

Finding: In one external report on uv 0.12.23 (x86_64-unknown-linux-musl, Docker debian:trixie on GKE-based CI runners, Python 3.11), uv sync with UV_GCS_ENDPOINT_URL pointed at Google Artifact Registry and GOOGLE_APPLICATION_CREDENTIALS set to a workload identity federation (external_account) config failed with 403 Forbidden when downloading wheels ([issue](https://github.com/astral-sh/uv/issues/22273)). Reporter-described diagnosis: The reporter says the cause was only visible with RUST_LOG=reqsign_core=debug. In the reporter's account, reqsign-google could not parse the credential file; the reporter quotes the message 'data did not match any variant of untagged enum Source' and ties it to credential_source.format being missing. The reporter further says uv then fell back to the GCE metadata server and signed requests as the node's default service account ([issue](https://github.com/astral-sh/uv/issues/22273)). The source does not explicitly state that this fallback identity caused the 403; any such link is an unverified inference. The reporter links an upstream reqsign issue (https://github.com/apache/reqsign/issues/909), but its content was not supplied here, so the dependency-side cause is unverified. The quoted error string is reporter-quoted, not independently verified. All of this is a single unreproduced report. Observability gap: According to the report, default verbosity and even -v give no hint that the configured credentials were ignored. The reporter requests that uv fail or at least warn when GOOGLE_APPLICATION_CREDENTIALS is set but cannot be loaded, and that reqsign credential-loading warnings be included in -v output ([issue](https://github.com/astral-sh/uv/issues/22273)). Diagnostic hint (report-derived): If a GCS-endpoint uv sync returns 403 while an external_account credential file is configured, one option is to check whether the credential is being loaded, for example by running with RUST_LOG=reqsign_core=debug as the reporter did, and looking for a parse error like the one reported. Whether requests are signed as a different identity is a hypothesis, not established by the source. Workaround (reporter-listed, not verified): The reporter lists adding "format": {"type": "text"} to credential_source in the credential config as a workaround ([issue](https://github.com/astral-sh/uv/issues/22273)). No explicit success confirmation is given, and no one else has confirmed it. Status: The issue was open on 2026-10-07 with no comments, no maintainer response, and no uv fix or release identified in the supplied data. Later status is not established. Limitations: This is a single external report. It was not reproduced by KFA, and there is no independent reproduction. Behavior on other uv versions or other credential types is unknown.