deploy: a KEDA external scaler, not a metrics-api shim

The feedback said "no KEDA integration". That is stale — deploy/keda/ has three manifests
(scaled-object.yaml, scaled-object-prometheus.yaml, scaled-job.yaml) and they work.

But look at what they do:

triggers:
  - type: metrics-api
    metadata:
      url: "http://flexiq-scaler:9091/api/scaler"
      valueLocation: "metricValue"

metrics-api is KEDA's generic "scrape a number from a URL" trigger. It requires the operator to
deploy a second process (flexiq scaler), configure its address in two places, and hand-write
the valueLocation JSON path. Every queue is a separate ScaledObject with a separate scaler
URL. There is no discovery, no auth on the scaler endpoint, and a typo in valueLocation fails
silently as "no scaling".

KEDA's external scaler protocol is a small gRPC service — IsActive, GetMetricSpec,
GetMetrics, and optionally the StreamIsActive push variant. Implementing it gives:

• type: external with scalerAddress, and queue selection as trigger metadata rather than a
  URL query string
• scale-to-zero driven by IsActive instead of a threshold comparison on a scraped integer
• StreamIsActive, so a queue going from empty to non-empty wakes a replica immediately rather
  than at the next 15-second poll
• TLS and auth on the scaler channel, which the HTTP endpoint does not have

FlexiQ already serves gRPC. This is another small service on the same stack. Keep the existing
manifests working and documented — the metrics-api path is the right answer for someone who
does not want a second service.

Start with deploy/keda/scaled-object.yaml, deploy/keda/scaled-object-prometheus.yaml, and deploy/keda/scaled-job.yaml, then read KEDA's external scaler protocol and the existing gRPC service. Define how queue metadata, IsActive, GetMetricSpec, GetMetrics, and optional StreamIsActive map onto FlexiQ. Done means the external-scaler manifests and documentation work while the existing metrics-api path remains available.