feat: add should_complete to CompletionConfig

[ayushiahjolia]

Issue #, if available: #519

Description of changes:
Adds a should_complete predicate to CompletionConfig for map and parallel operations, giving full control over when a batch completes early.

from aws_durable_execution_sdk_python import complete_batch, continue_batch

config = CompletionConfig(
    should_complete=lambda status: (
        complete_batch() if status.success_count >= 2
        else continue_batch()
    )
)

The predicate receives a CompletionStatus snapshot (counts + per-item statuses) and returns a CompletionDecision - either continue_batch() or complete_batch(outcome). The outcome determines whether CUSTOM_COMPLETION_SUCCEEDED or CUSTOM_COMPLETION_FAILED is reported.

Key design decisions -

• Cannot be combined with threshold fields (raises ValidationError)
• Predicate must be deterministic and side-effect-free
• Replay uses the checkpointed decision, never re-invokes the predicate
• On resumed invocations, deferred until prior checkpoints replay

Testing -

• Unit tests, integration tests and examples

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

[github-actions]

Codex AI review

[P1] Block new work while restoring terminal events. The restoration gate only suppresses predicate evaluation; scheduling remains enabled. With two restored terminal branches and max_concurrency=2, the first replayed event frees a slot and causes a previously unstarted third branch to execute before the second event opens the gate. This can introduce new durable side effects during replay. Track previously existing branches and admit only those until restoration and predicate evaluation are complete.

[github-actions]

Codex AI review

[P1] Persist the custom completion decision itself. Re-evaluating only after all terminal child checkpoints replay does not reproduce the status that originally triggered the decision. For example, a deterministic predicate that completes when success_count == 1 can fire live while a second branch has already checkpointed; if the invocation dies before the parent checkpoint, resume evaluates at two successes and continues with a different result. Synchronously checkpoint the decision/outcome when it fires, or explicitly restrict and validate predicates to monotonic decisions with stable outcomes.

[github-actions]

Codex AI review

Two replay-safety issues can change execution after a crash. Existing resume tests do not cover the decision-to-parent-checkpoint race window.

Reviewed commit 87a2c4a2faef5ca7c2b1e84ec132615a978dcb46. Workflow run