[sbalabanov]

TL;DR: Conclusion retries finish request status updates without changing the recorded batch outcome.

Summary

A batch can finish while some of its requests still lack their final status updates. This change finishes those updates when conclusion retries, keeping successful work successful and preserving the original failed or cancelled result. If the batch is still running, records are missing, or the message is invalid, keep the message for another attempt instead of guessing an outcome.

Repro

1. Start with a finished Succeeded batch containing two requests, then interrupt conclude after one final status update succeeds and the next status-log write fails.
2. Let the failed message reach conclude_dlq, then retry it after status-log writes work again.
3. Before: the message is discarded and missing updates stay missing. After: finish those updates as Landed, without turning successful work into an error.

Test Plan

• Successful, failed, and cancelled batches keep their matching request outcomes; later infrastructure errors do not replace the original result.
• A retry finishes missing request logs and leaves completed request states unchanged; it need not keep original timestamps or diagnostics. The partial-update test uses a Failed batch.
• The final queue keeps unfinished, missing, or invalid work available for another attempt.

Revert Plan

Pause conclude final processing before reverting. Retain final queue records
and request logs; do not reinterpret stored terminal outcomes as failures.

Issues