feat: add operator, CRD, and Helm parity for H2 config contracts

Summary

Track Kubernetes/operator/Helm parity for H2 config work, including recipes, entrypoints, signal registry, tenant scopes, backend-aware routing, and versioned config snapshots.

Parent roadmap: #2287 Related: #2326, #2330, #2331, #2332, #2342 Related code: deploy/operator/api/v1alpha1, deploy/operator/controllers, deploy/helm, deploy/kubernetes, src/semantic-router/pkg/apis, src/semantic-router/pkg/k8s, src/semantic-router/pkg/dsl

Motivation

The router config contract is moving toward versioned snapshots, global signal registry, recipes, entrypoints, and backend-aware routing. The operator currently passes canonical routing through ConfigSpec.Routing and has VLLMEndpoints discovery, but new H2 config capabilities need explicit CRD/operator/Helm translation and validation plans so Kubernetes deployments do not lag behind file-based configs.

Scope

Define and implement parity for:

• CRD schema and admission behavior for H2 config families;
• controller canonical-config translation for recipes/entrypoints/tenant scopes/backend refs;
• Helm values and examples for file-based and CRD-based flows;
• DSL/k8s conversion tests for new routing contracts;
• upgrade and compatibility behavior for existing VLLMEndpoints and ConfigSpec.Routing users.

Non-goals

• Do not duplicate the full router schema as hand-written CRD fields when pass-through objects are safer.
• Do not put controller translation logic into API type definitions.
• Do not break existing operator deployments that only use current routing config.

Acceptance criteria

• Each H2 config contract has an explicit Kubernetes/operator handling path or a documented non-goal.
• Operator-generated canonical config can represent recipes, entrypoints, and backend refs when supported.
• Helm examples cover at least one H2 config path.
• CRD/webhook/controller tests cover validation and translation behavior.