[nicoloboschi]

Fixes #5589.

Problem

A retain extracts chunks in parallel and writes them in batches. When a chunk failed (embeddings or LLM outage), the other chunks kept going and the final batch was still written. That first write deletes the document's previous memories and overwrites original_text; only then was the error raised. A chunk that extracts 0 facts never calls embeddings, so during an embeddings outage it "succeeded" — and that was enough to leave the document with 0 memories.

Fix (engine/retain/orchestrator.py)

• The producer stops at the first failed chunk and cancels the remaining extractions (their output would be thrown away anyway).
• The consumer discards every batch once a chunk has failed — both mid-stream and at the end-of-stream flush.

Known limit: a document large enough to write several batches (>100 chunks by default) can still have its first batch committed before a later chunk fails. Retrying the same content resumes from there (existing recovery path); making that fully atomic would defeat the streaming memory bound.

Tests

• hindsight-api-slim/tests/test_retain_failed_chunk_keeps_document.py — fails on main (previous memories deleted), passes here.
• hindsight-system-tests/tests/test_65_provider_outages.py — new blackbox stories (all 4 fail on main):
  • embeddings outage during an update keeps the previous version, and the update lands once the backend is back
  • LLM 503 during an update, same
  • an outage on a first retain leaves no document; the retry yields one copy of each fact
  • async retain during an outage fails, keeps the old version, and retry_operation applies the update whole
• The system-test stub can now fail embeddings with a given status (stubs.embeddings.fail_with_status).