fix(retain): fail when oversized chunk cannot split

[kamilfurtak]

Summary

In Hindsight 0.9.1, the retain output-retry splitter logs a warning and returns an empty result when an overlong sub-chunk cannot be split any further. The caller then treats that result as successful extraction, which can allow an operation to report completed while the sub-chunk's data was silently lost.

This draft PR changes only that terminal branch:

• keep the existing minimum-size/no-progress decision in _split_chunk_for_output_retry;
• raise a descriptive RuntimeError when an OutputTooLongError cannot be followed by a valid split;
• let the existing extract_facts_from_text failure propagation mark the retain as failed/retryable instead of committing a partial result.

Reproduction / impact

1. A retain chunk raises OutputTooLongError.
2. _split_chunk_for_output_retry returns None because the chunk is too small or cannot be reduced.
3. Before this change, _extract_facts_with_auto_split returned ([], TokenUsage()) and logged that it was dropping the sub-chunk.
4. The extraction could therefore continue with missing data and eventually report success.

The regression test uses a one-character chunk and a mocked OutputTooLongError; it now verifies that the helper raises and makes exactly one extraction attempt. Splittable chunks and the standard successful extraction path are unchanged.

Scope

• Hindsight version: 0.9.1
• Separate from the nested [[{turn}, ...]] splitter fix in fix(retain): preserve nested conversation chunks during output retry #3652.
• Separate from the strict-schema flag fix in fix(retain): honor retain strict-schema flag #3653.
• Separate from the facts-array saturation guard in fix(retain): guard saturated fact extraction output #3654.

Validation

• tests/test_fact_extraction_retry.py: 25 passed
• Ruff check: passed
• Ruff format check: passed

The repository hook was not used because this checkout does not have uv installed; the equivalent targeted Ruff checks were run directly.

---

Depends on #3652

Without #3652, conversation payloads wrapped in an extra array cannot be split at
all, so this change would turn a recoverable case into a hard failure. #3652 makes
those splits succeed; this PR then only fails when a chunk genuinely cannot be
reduced further.

Partial results are preserved

The recursive split previously gathered sub-chunk results without
return_exceptions, so one unsplittable half discarded facts the other half had
already extracted. That is the same data-loss shape this PR is meant to remove, so
sub-chunk results are now collected tolerantly:

• some halves fail, others succeed -> keep the extracted facts, log the partial
  failure at error level with counts
• every half fails -> re-raise, so the operation cannot report success

The remaining trade-off is deliberate: a partially-failed chunk still completes,
with the loss visible in logs rather than silent at the operation level.

[kamilfurtak]

Superseded by #3657, which combines this with the related recovery fix and derives the saturation bound from the configured output budget instead of hard-coding it. Depends on #3656.