Replace Document Original

Upload a NEW version of a document's retained original file (TOS-2452).

Unlike PUT .../content (which edits the TEXT and keeps a text original in sync), this replaces the ORIGINAL FILE itself - the "upload a new version" flow for a document that retains an original, including a binary one (pdf/docx). The uploaded bytes become the new original; text is re-extracted from them with the same extractor the bulk-ingest job uses (services.file_extractors.extract_text_for_filename), and that extracted text becomes the document's full_text via the normal save fan-out. Media documents (document_kind == 'media') are out of scope - those are replaced by re-uploading via POST /api/folders/media instead.

Guard order: visibility (404) -> edit rung on shared docs (403) -> document_kind must be 'text' (409 not_editable_kind) -> an original must already be retained (409 original_not_retained) -> base64/size (400/413) -> extraction must yield non-empty text (422 "could not extract text").

Ordering/transaction note: the object-store PUT and the doc.original_* metadata updates happen BEFORE save_document_content runs, in that order, so the metadata update lands on the SAME doc object save_document_content commits - if its own transaction later fails and rolls back, the metadata rolls back with it. The object-store PUT itself is NOT part of that transaction (object stores aren't transactional), so the OLD bytes are snapshotted first and restored best-effort when the save core fails - the desync window shrinks to "the compensating restore also failed", which is reported to Sentry (adversarial review on #3964, P3; a binary original is higher-stakes than the text-resync path this was modeled on). save_document_content is called with sync_original_bytes=False so it does not overwrite the just-written binary with the extracted text.