What Problem This Solves

extensions/voyage/embedding-batch.ts makes several unbounded reads of
external, untrusted Voyage batch responses. A misconfigured / hostile /
SSRF-reachable endpoint (including a self-hosted baseUrl override) can return a
Content-Length-less body that streams forever — and each unbounded read buffers
the entire payload before we can act on it, driving the batch worker into
memory pressure / OOM or a hang. Three reads are affected: the batch status
JSON, the batch error-file body, and the non-OK (4xx/5xx) diagnostic
body. This is the same untrusted-body surface the merged response-limit campaign
(#95218 / #96027 / #96038) closes across the other bundled providers.

The two success-body reads were bounded in the first revision of this PR. This
revision closes the last remaining gap: the non-OK diagnostic body.
assertVoyageResponseOk still read the failure body with an unbounded
await res.text() before throwing (and a duplicate unbounded
await contentRes.text() existed on the non-OK output-file branch in
runVoyageEmbeddingBatches), so a hostile endpoint returning a 500 with an
unbounded body was still buffered whole on the error path. Both non-OK reads are
now bounded too.

Changes

• Non-OK diagnostic body (assertVoyageResponseOk): now read through the
  shared readResponseWithLimit (16 MiB cap, media-core bounded reader,
  re-exported via openclaw/plugin-sdk/response-limit-runtime) instead of
  await res.text(). The ${context}: ${status} ${text} diagnostic is preserved
  byte-for-byte for under-cap bodies; on overflow it throws a bounded
  ${context}: ${status} (error body exceeds <N> bytes) and cancels the stream.
  Cap is threaded from each caller so the boundary is testable.
• Non-OK output-file branch (runVoyageEmbeddingBatches): now routes through
  the same assertVoyageResponseOk (same voyage batch file content failed: <status> <text> message) instead of its own unbounded await contentRes.text() — removing the last unbounded read in the file.
• Success-body reads (unchanged from the prior revision): status via
  readProviderJsonResponse, error file via readResponseWithLimit. The
  error-file path still fail-softs by design — an oversized error body
  degrades to formatUnavailableBatchError (cap value included so truncation is
  visible) rather than crashing the worker; the normal NDJSON
  trim/split/JSON.parse/extractBatchErrorMessage chain and the empty-file branch
  are preserved.
• No new abstraction — reuses the shared media-core bounded reader already used
  across the codebase. Plugin-scoped.

Real behavior proof

• Behavior addressed: Three untrusted Voyage batch reads must not buffer an
  oversized / never-ending body whole. The success-status read, the success
  error-file read, and the non-OK diagnostic read must each stop at the cap,
  cancel the stream, and either throw bounded or fail-soft — while valid small
  bodies (status JSON, NDJSON error file, empty error file, small non-OK
  diagnostic) still parse / format unchanged.
• Real environment tested: A real node:http server (createServer) bound to
  127.0.0.1, streaming bodies in 64 KiB chunks with no Content-Length
  (~64 MiB per overflow route, 4× the 16 MiB cap) over a real loopback socket,
  on Node v22.22.0. The real exported fetchVoyageBatchStatus and
  readVoyageBatchError (testing exports of the real module) were driven against
  it, with withRemoteHttpResponse performing a real fetch() and feeding the
  real Response into the real onResponse — so the production
  assertVoyageResponseOk + readResponseWithLimit / readProviderJsonResponse
  run exactly as in production.
• Exact steps: node --import tsx voyage-proof.mts — boot the server →
  drive the real functions against the streaming overflow routes and the small
  routes → after each overflow, wait for the server-side socket-close event and
  read the server's observed bytes-sent / abort counters → run a negative control
  (raw unbounded read of the same non-OK route).
• Evidence after fix (all 11 checks PASS):
  • A — status success overflow: real fetchVoyageBatchStatus threw
    voyage-batch-status: JSON response exceeds 16777216 bytes; the server saw the
    socket aborted after ~17 MiB (≪ the ~64 MiB it would have sent) → stream
    cancelled, not drained.
  • B — error-file success overflow: real readVoyageBatchError fail-softed
    to error file unavailable: voyage batch error file content exceeds 16777216 bytes (no throw out of the worker); socket aborted after ~17 MiB.
  • C — NON-OK diagnostic overflow (the gap this revision fixes): a streaming
    500 drove assertVoyageResponseOk to throw the bounded
    voyage batch status failed: 500 (error body exceeds 16777216 bytes); socket
    aborted after ~18 MiB ≪ ~64 MiB. Before this fix the 500 body was buffered
    whole by await res.text().
  • D — small / branch correctness: small status JSON parsed unchanged; the
    NDJSON error file still extracted the first error message
    (voyage upstream rejected); the empty error file returned undefined via the
    empty-body branch; a small non-OK body preserved the original
    voyage batch status failed: 503 voyage upstream is down diagnostic.
  • Negative control: a raw unbounded read of the same non-OK route
    buffered past the 16 MiB cap (16,790,567 > 16,777,216 bytes) — proving the
    cap is load-bearing (without it the body keeps accumulating).
• What was not tested: Did not hit the live api.voyageai.com endpoint (no key
  / would not reproduce a hostile oversized body); the untrusted-body behavior is
  fully reproduced with a local streaming server over a real socket, which is the
  same transport path. The proof drives the bytes-on-wire + early-socket-close
  signal (the load-bearing signal) rather than driving the worker to actual OOM.
  The proof script is not committed.

Evidence

Real node:http terminal proof (real loopback sockets, real exported functions):

[proof] real node:http server on http://127.0.0.1:42763, cap=16777216 bytes, would-stream≈67108864 bytes per overflow route

PASS  A status success overflow: real fetchVoyageBatchStatus throws bounded error :: threw=true msg="voyage-batch-status: JSON response exceeds 16777216 bytes"
PASS  A status overflow stream cancelled: server saw socket abort, bytes ≪ would-stream :: aborted=true bytesSent=17367040 (< 67108864)
PASS  B error-file success overflow: readVoyageBatchError fail-softs (no throw, degraded string) :: result="error file unavailable: voyage batch error file content exceeds 16777216 bytes"
PASS  B error-file overflow stream cancelled: server saw socket abort, bytes ≪ would-stream :: aborted=true bytesSent=17498112 (< 67108864)
PASS  C NON-OK diagnostic overflow (THE FIX): assertVoyageResponseOk bounds the 500 error body :: threw=true msg="voyage batch status failed: 500 (error body exceeds 16777216 bytes)"
PASS  C NON-OK overflow stream cancelled: server saw socket abort, bytes ≪ would-stream :: aborted=true bytesSent=17760256 (< 67108864)
PASS  D1 small valid status JSON still parsed unchanged :: {"id":"batch_1","status":"completed"}
PASS  D2 small NDJSON error file: full trim/split/parse chain still extracts first error :: message="voyage upstream rejected"
PASS  D3 empty error file: empty-body branch returns undefined :: message=undefined
PASS  D4 small NON-OK body: original `${context}: ${status} ${text}` diagnostic preserved :: threw=true msg="voyage batch status failed: 503 voyage upstream is down"
PASS  NEG control: raw UNBOUNDED read of /nonok-overflow buffers PAST the 16 MiB cap (cap is load-bearing) :: buffered=16790567 bytes (> 16777216)

[proof] 11 PASS, 0 FAIL
[proof] ALL PASS

In-repo Vitest suite (real ReadableStream fixtures, including the new non-OK
overflow + small non-OK diagnostic regression tests):

 Test Files  1 passed (1)
      Tests  8 passed (8)

Checks on the changed files: oxlint extensions/voyage/embedding-batch.ts extensions/voyage/embedding-batch.test.ts → exit 0, clean; tsgo -p tsconfig.extensions.json → exit 0, no errors.

Label: security

AI-assisted.