Document resumable transcription and replay

docs/integrations/whisperx.md

@@ -17,11 +17,20 @@ Narratio sends an HTTP `POST` to the configured transcription URL using
 The server must return a `2xx` response whose body is valid JSON. Narratio does
 not currently require a more specific response schema at this boundary.
 
-The transcription URL must be an absolute `http` or `https` URL. The audio body
-is streamed through a fresh multipart writer for every attempt, so its memory
-use is bounded by the transport buffer rather than by the complete audio file.
+The transcription URL must be an absolute `http` or `https` URL. Each
+application attempt creates one bounded multipart framing and streams the audio
+from an open file between that framing; it does not buffer the complete audio
+or spool a multipart copy. The file field precedes the language field.
 WhisperX response acquisition is capped at 10 MiB.
 
+The initial request body and any transport-requested replay use the same
+multipart boundary and framing. Every body opens an independent audio handle
+and replay starts at the beginning. Narratio closes all bodies created for the
+attempt on response, failure, timeout, or cancellation, including when a
+transport abandons an earlier body. Genuine source read/close failures remain
+request failures; deliberate early closure of an abandoned original does not
+poison a valid replay.
+
 ## Request And Result Contract
 
 Each adapter request identifies a speaker, a readable audio file, and the
@@ -43,6 +52,11 @@ transcript output.
 - Narratio waits the configured retry delay between attempts and aborts that
   wait when the parent context is canceled.
 
+Transport replay occurs inside one application attempt and does not consume an
+entry from the configured retry budget or increment the reported attempt
+count. The standard HTTP redirect policy remains in effect; body replay can
+also support body-preserving redirects.
+
 ## Validation And Failure Semantics
 
 Client construction rejects a missing or non-HTTP(S) absolute transcription URL,
@@ -55,12 +69,19 @@ failure to install the output causes the transcription to fail. Errors include
 attempt context, and the result retains attempts, final status when available,
 and elapsed duration for diagnostics.
 
+Replay makes a fresh request body available to the HTTP transport; it does not
+provide an exactly-once server guarantee and does not prove recovery from every
+proxy or protocol-level failure. A server may have received work before the
+client learns that a request failed. WhisperX operations should therefore be
+safe to retry for the same input when practical.
+
 ## Determinism And Concurrency
 
 Each audio request has stable multipart field names, and successful bytes are
 installed atomically. The transcribe stage may process speaker files in
-parallel, bounded by the configured concurrency. It records results in stable
-speaker order after all work completes; any speaker failure fails the stage.
+parallel, bounded by the configured concurrency. Each validated speaker is
+checkpointed independently; any speaker failure still fails the aggregate
+stage, while committed earlier speakers remain reusable on an ordinary retry.
 
 ## Related Canonical Docs