Problem

The item-streaming endpoint of the two-phase batch API (POST /api/v3/batches/:batchId/items) processed streamed items strictly sequentially. For a batch of many large payloads, each offloaded to object storage inline, this serialized N object-store round-trips inside a single request and could exceed Node's default server.requestTimeout (300s). The webapp then returned 408, which the SDK reads as 408 terminated and retries up to 5 times, turning a slow ingest into a failure that takes tens of minutes to surface.

Fix

Ingest now runs through p-map over the NDJSON async iterable with bounded concurrency (STREAMING_BATCH_INGEST_CONCURRENCY, default 10):

• p-map pulls lazily from the stream, so at most concurrency items are read and in-flight at once. Peak memory stays bounded to roughly concurrency × STREAMING_BATCH_ITEM_MAXIMUM_SIZE and request-body backpressure is preserved.
• Set the env to 1 for fully sequential ingestion (escape hatch).

Why this is safe (ordering and idempotency unchanged)

• Ordering derives from each item's index (enqueue timestamp = batch.createdAt + index), not enqueue order.
• Dedup is atomic per index in enqueueBatchItem.
• The NDJSON parser now stamps oversized-item markers with their emit position, removing the consumer's sequential lastIndex assumption (the only order-dependent bit).
• The count-check and conditional-seal path is untouched.

Scope

This speeds up every batch ingested through the streaming endpoint, not just large-payload batches. Each item does a per-item Redis enqueue regardless of size, and those now overlap. Large payloads benefit most because they add an object-store offload round-trip on top of the enqueue.

Verification

Added an integration test (streamBatchItems.test.ts) that drives the real service against Postgres + Redis + RunEngine and times a 150-item batch at increasing concurrency. Object-store offload is modelled as a fixed per-item latency (local round-trips are too small to compare meaningfully):

runCount=150
  large payloads (10ms/item offload):
    concurrency=1   1739ms
    concurrency=10  192ms  (9.1x faster)
    concurrency=50  57ms   (30.7x faster)
  small payloads (Redis enqueue only, no offload):
    concurrency=1   90ms
    concurrency=10  24ms   (3.7x faster)

The test asserts correctness at every concurrency (all items accepted, sealed, enqueued exactly once), that parallel ingest beats the sequential floor, and that the small-payload case is strictly faster than sequential, so the win is not specific to large payloads.

Also exercised end-to-end over real HTTP against a local server: a 20-item batch (12MB body) ingests and seals, a re-stream of the sealed batch returns sealed: true with zero re-accepted items (idempotent retry), and an oversized item still seals at its correct index.

Existing coverage stays green: concurrent ingest of a 100-item batch, in-flight processing never exceeding the configured concurrency, concurrent dedup on streaming retry, and emit-position marker indexing.

Follow-ups (not in this PR)

• SDK pre-offload of large item payloads (send application/store refs instead of raw blobs) to remove object-store work from the request hot path and shrink the request body.
• Optional server.requestTimeout bump as a safety net.