feat: install the platform with a Helm chart built from the manifests

[Yash-Chindam]

What

Adds the Helm chart the spec's deployment topology calls for (§17: "Docker, Kubernetes, Helm and GitHub Actions").

How

llm_router.chart builds deploy/helm/llm-routing from the reviewed manifests instead of duplicating them by hand. It lifts out only what an installation changes:

Value	Purpose
serving.mode	vllm (one engine) or ray (the Ray Serve overlay)
images.*	one digest-pinned reference per workload
gateway.replicas, gateway.autoscaling.*	gateway size and KEDA bounds

The namespace becomes the release namespace, and Prometheus templating in alert annotations is escaped so Helm passes it through. The chart owns no Namespace.

CD now fails if the committed chart is stale, lints it, and packages it as an artifact.

Tests

tests/unit/test_chart.py (11 tests). The important ones render the chart with real helm template and compare it, resource by resource, with real kubectl kustomize:

• default values render exactly the single-engine base;
• serving.mode=ray renders exactly the Ray overlay;
• overridden image, replica, autoscaling and namespace values reach the workloads;
• an unknown serving mode is refused;
• a stale, missing or hand-added chart file is reported.

These need helm and kubectl; they skip on a workstation without them and fail in CI if the tools are missing.

Local: ruff and mypy clean, 400 tests pass, 98% coverage.

Limits

• The chart has been rendered and linted, not installed on a cluster.
• It does not install the operators it depends on (KubeRay, KEDA, External Secrets, Prometheus Operator, GPU Operator).
• Chart version and appVersion come from pyproject.toml, which still says 0.1.0 while release tags are at v0.10.x; aligning them is a separate change.

🤖 Generated with Claude Code