google-cloud-developer: Developer Knowledge MCP server has no auth path in Claude Code (works in Gemini CLI)

## Summary

`google-cloud-developer` v1.1.1 bundles the Developer Knowledge MCP server, but the Claude Code build ships no way to authenticate to it. The server accepts the MCP handshake and `tools/list` anonymously, then rejects every `tools/call` with an auth error. Claude Code reports the server as "Failed to connect" on every session start, and no lookup ever succeeds through the MCP transport. The skill still works via its curl fallback, which may be why this was not caught.

## Environment

- Claude Code (macOS), plugin installed with `claude plugin marketplace add google/skills` + `claude plugin install google-cloud-developer@google-plugins`
- Plugin version 1.1.1 (matches `main`)
- gcloud 582.0.0, authenticated

## What the two builds ship

`gemini-extension.json` (works in Gemini CLI):

```json
"developer-knowledge": {
"httpUrl": "https://developerknowledge.googleapis.com/mcp",
"authProviderType": "google_credentials"
}
```

`mcp.json` (Claude Code / Agent Plugins spec):

```json
"developer-knowledge": {
"type": "streamable-http",
"url": "https://developerknowledge.googleapis.com/mcp"
}
```

Claude Code has no equivalent of `authProviderType: google_credentials`. It can authenticate an HTTP MCP server two ways, and the plugin's config uses neither:

1. Static headers (e.g. `X-Goog-Api-Key`), optionally via `${ENV_VAR}` expansion.
2. OAuth discovery. The server does not advertise one: `/.well-known/oauth-protected-resource` returns 404 and responses carry no `WWW-Authenticate` challenge.

## Reproduction

```bash
# handshake and tool listing succeed anonymously
curl -s -X POST https://developerknowledge.googleapis.com/mcp \
-H 'Content-Type: application/json' -H 'Accept: application/json, text/event-stream' \
-d '{"jsonrpc":"2.0","id":1,"method":"tools/list","params":{}}'
# -> 200, three tools listed

# any real call fails
curl -s -X POST https://developerknowledge.googleapis.com/mcp \
-H 'Content-Type: application/json' -H 'Accept: application/json, text/event-stream' \
-d '{"jsonrpc":"2.0","id":2,"method":"tools/call","params":{"name":"search_documents","arguments":{"query":"gcloud auth login"}}}'
# -> {"isError":true, "content":[{"text":"Request is missing required authentication credential. Expected OAuth 2 access token, login cookie or other valid authentication credential. ..."}]}
```

The same `tools/call` with `Authorization: Bearer $(gcloud auth print-access-token)` succeeds, so the server is fine; the plugin just has no way to hand it a credential from Claude Code.

```
$ claude mcp list
plugin:google-cloud-developer:developer-knowledge: https://developerknowledge.googleapis.com/mcp (HTTP) - ✘ Failed to connect
```

Plugin-bundled MCP servers cannot be individually disabled or have headers overridden in Claude Code, so users cannot patch around this without editing the plugin cache (which is wiped on update).

## Suggested fix

Any one of these would unblock Claude Code users:

- Add an env-var header to `mcp.json`, matching the credential the skill already documents:
```json
"headers": { "X-Goog-Api-Key": "${DEVELOPERKNOWLEDGE_API_KEY}" }
```
and document the variable in the plugin README.
- Have the Developer Knowledge server publish OAuth protected-resource metadata so MCP clients can run a standard login flow.
- Failing both, drop the server from the Claude Code `mcp.json` and rely on the skill's documented curl fallback, so users do not see a permanently failing server.

## Workaround for others hitting this

Register the server yourself with an API key restricted to `developerknowledge.googleapis.com` (note `--header` must come after ` `):

```bash
claude mcp add --transport http --scope user google-dev-knowledge \
https://developerknowledge.googleapis.com/mcp \
--header "X-Goog-Api-Key: YOUR_KEY"
```

The plugin's skills then use this server and work as intended. The plugin's own server entry keeps showing "Failed to connect" but is otherwise harmless.

Read mcp.json alongside gemini-extension.json and the plugin README to compare the available authentication paths and documented fallback. Reproduce the anonymous handshake and authenticated tools/call, then confirm the chosen resolution either authenticates the bundled server or removes the failing entry while leaving the fallback documented.

Written by the indexing model from the issue text.