Bug: Google HTTP MCP servers fail with serviceusage.services.use while local Google MCP adapter works

## Summary

When using Google Cloud MCP servers from Copilot CLI, a local Google MCP adapter works, but Google-managed remote HTTP MCP servers fail with a permissions error even though IAM and impersonation are configured correctly.

In the same environment:

- a local `observability` MCP server works
- Google-managed `logging` and `developerknowledge` HTTP MCP servers fail
- direct impersonated HTTP calls to the same Google-managed MCP endpoints succeed
- Gemini CLI can access the same project successfully

This makes it look like Copilot CLI's Google HTTP MCP auth path is using the wrong effective Google identity, or not honoring the intended ADC / impersonated identity.

## Affected version

GitHub Copilot CLI `1.0.7`

## Environment

- OS: macOS (Darwin)
- Project: `yourproject-id`
- Google Cloud remote MCP config uses `authProviderType: "google_credentials"`
- ADC quota project is set to `yourproject-id`

## Problem detail

### What works

1. Local MCP server: `observability` (from `gcloud-mcp`)
- Copilot talks to a local MCP process
- The local process uses local Google auth itself
- This works successfully against the project

2. Direct impersonated HTTP calls to Google-managed MCP endpoints
- `https://logging.googleapis.com/mcp`
- `https://developerknowledge.googleapis.com/mcp`
- These succeed when called directly with an impersonated access token

3. Gemini CLI in the same environment can use the same Google Cloud project successfully

### What fails

Google-managed remote HTTP MCP servers configured in `~/.copilot/mcp-config.json` with `authProviderType: "google_credentials"`:

- `https://logging.googleapis.com/mcp`
- `https://developerknowledge.googleapis.com/mcp`

These fail in Copilot CLI with a permission error consistent with the request reaching Google under the wrong effective identity.

## Error

The failure is:

```text
serviceusage.services.use
```

More specifically, the error indicates the caller does not have the required `serviceusage.services.use` permission, even though the intended user/service-account path does have the required roles.

## Why this looks like a Copilot CLI auth-path bug

The key distinction is:

- `observability` works because it is a **local MCP server**. Copilot talks to a local process, and that process uses local Google auth itself.
- `logging` / `developerknowledge` fail because they are **Google-managed remote HTTP MCP servers**. Copilot must attach Google credentials directly when calling `logging.googleapis.com/mcp` / `developerknowledge.googleapis.com/mcp`.

Since all of the following are true:

- local `observability` works
- Gemini CLI works
- direct impersonated HTTP calls work
- IAM roles are present
- quota project is configured

…the remaining failure seems specific to Copilot CLI’s handling of Google credentials for remote HTTP MCP servers.

## IAM / auth verification already performed

The following were verified in the affected project:

- user has `roles/mcp.toolUser`
- user has `roles/serviceusage.serviceUsageConsumer`
- ADC quota project is set correctly
- a dedicated service account was created and granted the same relevant project roles
- user was granted `roles/iam.serviceAccountTokenCreator` on that service account
- direct impersonated access-token calls to the failing MCP endpoints succeed

This strongly suggests project-side IAM is not the root cause.

## Reproduction sketch

1. Configure a local Google MCP adapter such as `observability` and confirm it works.
2. Configure a Google-managed remote HTTP MCP server like this:

```json
{
"mcpServers": {
"logging": {
"type": "http",
"url": "https://logging.googleapis.com/mcp",
"authProviderType": "google_credentials",
"oauth": {
"scopes": ["https://www.googleapis.com/auth/cloud-platform"]
},
"headers": {
"x-goog-user-project": "yourproject-id"
}
}
}
}
```

3. Restart Copilot CLI.
4. Call a `logging-*` tool.
5. Observe `serviceusage.services.use` permission failure.
6. Independently call the same endpoint with a direct impersonated access token.
7. Observe that the direct call succeeds.

## Expected behavior

If Copilot CLI is configured to use Google credentials for a Google-managed HTTP MCP server, it should use the same effective Google identity that succeeds via local Google tooling / ADC / impersonation, or at least fail in a way that makes the effective principal obvious.

## Actual behavior

Local Google MCP adapter works, but Google-managed remote HTTP MCP calls fail with `serviceusage.services.use`, despite verified IAM and successful direct impersonated calls.

## Request

Could you please confirm whether Copilot CLI’s `google_credentials` auth path for HTTP MCP servers:

- honors impersonated ADC / application-default credentials as expected
- may be selecting a different credential source than local Google tooling
- can surface which Google principal it is actually using for the remote HTTP MCP request

That would help determine whether this is a CLI auth-source bug, an ADC/impersonation support gap, or an expected limitation.