Add an agentgateway-based multi-provider AI gateway blueprint for GKE

## Summary

I would like to contribute an agentgateway-based multi-provider generative AI gateway solution for GKE.

The proposed solution would let users deploy a single agentgateway data plane that can route OpenAI-compatible requests to:

- Vertex AI and Gemini
- External providers such as OpenAI and Anthropic
- Self-hosted models represented by Gateway API Inference Extension `InferencePool` resources

This would be additive. It would not replace or change the existing GKE Inference Gateway blueprint.

## Motivation

Cluster Toolkit already provides the infrastructure needed for AI workloads on GKE and includes a blueprint that prepares a cluster for GKE Inference Gateway. However, there is currently no end-to-end blueprint for a multi-provider AI API gateway spanning Google-hosted models, external providers, and self-hosted models on GKE.

Agentgateway is an open source Gateway API implementation that supports both multi-provider LLM routing and the Gateway API Inference Extension. It can route to an `InferencePool` directly, or through an `AgentgatewayBackend` when token rate limits, guardrails, transformations, and LLM observability are also required.

This is similar in intent to AWS's multi-provider generative AI gateway guidance, but would use Cluster Toolkit's existing GKE and Google Cloud modules instead.

## Proposed architecture

```text
Applications
|
Cloud Load Balancing (internal by default)
|
agentgateway on GKE
|
+-- Vertex AI / Gemini
+-- External model providers
`-- AgentgatewayBackend --> InferencePool --> EPP --> model servers on GKE
```

Agentgateway would be the single gateway data plane. The Endpoint Picker Extension would continue to select replicas within each `InferencePool`.

## Proposed repository approach

Start with a community blueprint under a path such as:

```text
community/examples/agentgateway-gke/
```

The blueprint would compose existing Cluster Toolkit modules wherever possible:

- `modules/network/vpc`
- `modules/project/service-account`
- `modules/project/workload_identity_binding`
- `modules/scheduler/gke-cluster`
- `modules/compute/gke-node-pool`
- `community/modules/management/direct-helm-install`
- `modules/management/kubectl-apply`

The agentgateway CRD and controller OCI charts would be version-pinned. I would only propose a dedicated module under
`community/modules/management/agentgateway` if the existing generic Helm and manifest modules cannot provide reliable dependency ordering or lifecycle management.

## Initial contribution scope

The first PR would provide a CPU-only, affordable deployment that includes:

- A regional GKE Standard cluster
- Workload Identity Federation for GKE
- A least-privilege service account for Google Cloud APIs
- Version-pinned agentgateway CRD and controller charts
- An agentgateway `Gateway` and OpenAI-compatible endpoint
- A Vertex AI backend using workload credentials
- Optional references to pre-existing Kubernetes secrets for external providers
- Internal load-balancer exposure by default
- Cloud Logging and Prometheus-compatible metrics
- Deployment, validation, usage, and cleanup documentation
- A smoke test for synchronous and streaming requests

Secret values would not be embedded in the blueprint or stored directly in Terraform state.

## Follow-up scope

After the base deployment is accepted, I propose follow-up PRs for:

1. `InferencePool` routing with a pinned llm-d Router/EPP and a lightweight simulator for CI, followed by documentation for composing the solution with Cluster Toolkit GPU node pools and vLLM.
2. Optional production ingress using an external HTTPS load balancer, Certificate Manager, Cloud DNS, and Cloud Armor.
3. Optional Model Armor policies and Secret Manager CSI integration.

## Compatibility question

The current `gke-cluster` module couples Gateway API enablement and Inference Extension CRD installation to `enable_inference_gateway`, and currently pins the Inference Extension manifests to `v1.0.0`. Current agentgateway examples
use newer Inference Extension releases.

Before implementing the blueprint, I will validate the supported GKE, Gateway API, Inference Extension, agentgateway, and llm-d version combination. Depending on the result, the cleanest approach might be to make generic Gateway API enablement and the Inference Extension version independently configurable while preserving the existing behavior by default.

## Non-goals for the initial PR

- Replacing the existing GKE Inference Gateway implementation
- Requiring GPUs merely to validate the blueprint
- Deploying a database, Redis, or other LiteLLM-specific persistence
- Deploying MCP or A2A examples
- Storing provider credentials directly in the repository or blueprint

## Proposed validation

- Run Cluster Toolkit pre-commit and blueprint validation checks
- Generate the deployment with `gcluster create`
- Run Terraform formatting and validation
- Render and validate the pinned Helm charts and Kubernetes resources
- Deploy to an ephemeral CPU-only GKE cluster
- Verify the `Gateway` becomes programmed and its workloads become ready
- Exercise synchronous and streaming requests through Vertex AI
- Exercise `InferencePool` routing with a simulator in the follow-up
- Destroy the deployment and verify that managed resources are removed

I am willing to implement the blueprint, tests, and documentation and remain involved in maintenance and review.

## Questions for maintainers

1. Is this solution aligned with Cluster Toolkit's AI/ML scope?
2. Is a blueprint-first contribution under `community/examples` the preferred starting point?
3. Should generic Gateway API enablement be separated from the existing `enable_inference_gateway` setting, or should this solution reuse it?
4. Do you prefer the multi-provider base and `InferencePool` integration in one PR or as the phased PRs described above?
5. Is internal load-balancer exposure an acceptable secure default for the initial contribution?

## References

- [agentgateway](https://github.com/agentgateway/agentgateway)
- [Agentgateway Inference Extension integration](https://agentgateway.dev/docs/kubernetes/latest/inference/)
- [Agentgateway Vertex AI provider](https://agentgateway.dev/docs/kubernetes/latest/llm/providers/vertex/)
- [Existing Cluster Toolkit GKE Inference Gateway blueprint](https://github.com/GoogleCloudPlatform/cluster-toolkit/blob/develop/examples/gke-a3-highgpu-inference-gateway.yaml)
- [AWS multi-provider generative AI gateway guidance](https://github.com/aws-solutions-library-samples/guidance-for-multi-provider-generative-ai-gateway-on-aws)