epic: the operational surface exists but stops one step short

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.

Treat the six items as independent workstreams, starting with the existing deployment surface: deploy/helm/flexiq-server, deploy/keda/, and the ghcr.io/byteveda/flexiq-server image. Check how the current metrics-api trigger, SDK test harnesses, tracing, and server API are implemented before choosing one item. Done means one operational gap is implemented or documented with a verifiable integration, without expanding the default embedded deployment model.