Fix orphaned batch_retain parents when child fails via unhandled exception

[cdbartholomew]

Problem

When a child retain operation fails with an unhandled exception (e.g. a database constraint violation), two things happen:

1. The memory engine's transaction is rolled back entirely — including the call to _maybe_update_parent_operation that would normally update the parent batch_retain.
2. The poller's fallback _mark_failed runs and correctly marks the child as failed, but it has no awareness of the parent relationship.

This leaves the parent batch_retain operation permanently stuck in pending state, which causes the worker queue to appear degraded. Failures of this kind have been observed across documents in various languages (Turkish, Polish, Russian, and Spanish content) where character encoding edge cases can trigger constraint violations.

Fix

Wrap _mark_failed in a transaction and call a new poller-level _maybe_update_parent_operation after marking the child failed. This mirrors the memory engine's own parent-update logic and ensures the parent is resolved regardless of how the child failure was detected.

The poller's implementation:

• Locks the parent row to prevent concurrent sibling race conditions
• Checks all siblings before finalising — only resolves parent once all are in a terminal state
• Marks parent failed if any sibling failed, completed if all succeeded
• Errors in parent propagation are logged but do not affect the child failure path

Tests

Added TestMarkFailedParentPropagation covering:

• Last sibling fails → parent batch_retain becomes failed
• Sole child fails → parent becomes failed
• Sibling still pending → parent stays pending (no premature resolution)
• No parent_operation_id in result_metadata → safe no-op
• End-to-end: unhandled exception via execute_task propagates to parent

[nicoloboschi]

LGTM

this was a very bad code design initially, this one is much better