fix(workflows): preserve accepted completion batch receipts

[ooiuuii]

Problem

Fixes #572.

When a pending workflow completion backlog is split into several messages, a later synchronous send failure discards the earlier batches' success receipts. The existing result queue then retries completions that were already accepted.

Value

Avoid unnecessary duplicate completion delivery and duplicate parent-model context after a partial transport failure.

Approach

Track accepted delivery IDs after each successful batch. On failure, stop sending further batches as before, but return per-envelope receipts: success for accepted IDs and failure for the rest. The existing queue retains ownership of durable persistence and later lifecycle retry.

This does not introduce an exactly-once transport promise. The documented at-least-once behavior after durable receipt persistence failure is unchanged.

Validation

• Actual recovery path: persistWorkflowJson -> workflows(pi) -> session_start -> agent_settled. A 400-run backlog with normal IDs reaches real bounded batching; batch one is accepted and batch two throws.
• RED: an already accepted run is wrongly persisted as pending. GREEN: the next lifecycle delivers only unconfirmed runs; all 400 are accepted once, with durable attempt counts 1 for prior successes and 2 for the rest.
• Focused completion recovery / queue / prompt / rendering / shared inbox tests: 56/56 pass.
• Existing sandbox transport-failure and shutdown-recovery E2E cases: 2/2 pass.
• bun run check, git diff --check, one scoped read-only review — pass/no actionable findings.
• No live provider or private session was used. Full local suite not claimed green: separately reproduced host baseline timeouts and Windows child-cleanup hang were not repeated. Fresh branch CI will run the broader suite.

Impact

• User/model-visible: previously accepted completions are not needlessly reissued after a later batch fails.
• Runtime/lifecycle: preserves known per-run acknowledgements in the current adapter; existing queue retry/persistence behavior remains authoritative.
• Tools/config/persisted format: unchanged.
• Compatibility/risk: no new timers, retry policy, idempotency store, payload limits, or workflow execution changes.