Keiko 0.3.14 — embedding batch degradation

Fixes

Indexing now completes against gateways that fail multi-text embedding requests.

Keiko embeds a document's sections in one batched request. It fell back to sending them one at a
time only when a gateway rejected that batch cleanly with HTTP 400 or 422. A gateway that answers
the same batch with a server error, a timeout or a dropped connection was treated as briefly
unavailable — so the identical request was retried unchanged. Indexing produced no vectors,
surfaced no error, and looked like it was running indefinitely. The capsule preflight embeds its
probe batch through the same path, so a run could die before its first document.

Measured against the affected deployment:

request	answer
one input	HTTP 200 in 0.21s
the same texts batched, with encoding_format	HTTP 400 (unsupported parameter)
36 texts batched	HTTP 500 after 18.87s

• Any batch failure that is not a clean rejection now triggers exactly one single-text attempt.
  If that succeeds, the batch shape is the problem: the endpoint is remembered and every later
  request for it is sent one text at a time, so the penalty is paid once rather than per document.
• If the single-text attempt fails too, the original error is reported unchanged — a genuine
  outage is still reported as an outage, at the cost of one extra request.
• A throttle (HTTP 429) is deliberately excluded: "try again later" says nothing about the request
  shape, so a passing rate limit no longer degrades an endpoint for the rest of the session.
• A cancelled run no longer fans out into further requests — including a cancellation that arrives
  after the gateway already answered.
• Deployment routing (endpointStyle, apiVersion) now travels with the single-text fallback.
  Previously an Azure deployment endpoint attempted the batch at its deployment URL and then probed
  the plain /embeddings path — a different endpoint, which could only report a false outage.

Operator action

Restart the Keiko process after updating; the running process keeps serving the old code even once
the footer reports 0.3.14. No gateway re-setup is required, and existing Knowledge Pods can be
re-indexed directly.

npm install -g @oscharko-dev/keiko@0.3.14