Stores one item of a job from a multipart upload. A batch's items arrive
one per request. The item carries either a document extraction
(whose input file rides as raw bytes in the file part) or a
create extraction (JSON only, no file).

The upload enforces these rules:

• Set exactly one of document or create. Setting both, or
  neither, is a 400.
• When document is set, file is required — it supplies the
  document's binary content (PDF or image).
• When create is set, file is forbidden — a create item carries
  no file.
• document and create must each be a JSON object.

Only the item's structure is checked here: the fields inside document
or create are not validated at upload. A body that is well-formed JSON
but not a valid request for its endpoint is still accepted with 202
and fails later during processing, recorded as an item error. A
wrong-typed field the endpoint cannot decode fails as invalid_input; a
body that decodes but the pipeline rejects (for example, a missing
required field) fails as processing_failed.

Supplying request_id makes the upload idempotent on that token. A
re-upload under the same token overwrites the same item rather than
adding a second, so a client that lost an upload's response can safely
re-send it. The response's deduplicated is true only when the
re-uploaded payload matches the one already stored; a same-token upload
with a changed payload overwrites in place and returns false.

Set a request_id on every upload: re-sending under the same token
is the only way to repair a lost or incomplete upload, including the one
a finalize 409 reports. Without one, a re-send adds a new item instead
of replacing the missing one, and the job cannot be finalized.

Uploads are rejected once the job has been finalized (409), once it
holds its 500-item limit (409), or when the item is too large (413 —
see the raw-file limit in the API description).