epic: the operational surface exists but stops one step short #856

Why

The 2.0 server is deployable — a distroless multiarch image at
ghcr.io/byteveda/flexiq-server, a Helm chart at deploy/helm/flexiq-server, KEDA manifests at
deploy/keda/, a readiness probe and an admission webhook. Most of the operational surface
exists.

What it lacks is the last mile in each case: the image has no docker/README.md and no tag
policy anyone can read; the Helm chart's README is in the repository and nowhere on the docs
site; the KEDA integration is a metrics-api trigger pointed at an HTTP endpoint rather than a
real external scaler; nothing declares FlexiQ resources from Terraform; cross-language trace
propagation is either unimplemented or undocumented and nobody can tell which; and only one SDK
ships a test harness.

Each item is small. Together they are the difference between "you can run this" and "this is a
platform component".

Shape

Six independent items, none blocking another:

• a real KEDA external scaler
• a Terraform provider
• the container image documented, with a tag policy
• the Helm chart surfaced on the docs site
• cross-language trace propagation verified, then documented or implemented
• flexiq dev — an in-memory server over gRPC, so every language gets a test harness

What this is not

Not a Kubernetes-first pivot. Embedded, no daemon, straight to SQLite stays the default.
These make the server deployment good for the people who chose it; they do not make the cluster
the recommended shape.

Not an integration for the sake of a logo. A Terraform provider that lags the API is worse
than none. Anything here that cannot be kept current should not be started.