Summary

• Refactor map/parallel completion so every completion path is evaluated through CompletionConfig.shouldComplete as a CompletionDecision.
• Keep existing public completion configs (allCompleted, allSuccessful, firstSuccessful, minSuccessful, tolerated failure configs) by building them on top of the same decision function.
• Add custom completion statuses with explicit success semantics: CUSTOM_COMPLETION_SUCCEEDED and CUSTOM_COMPLETION_FAILED.
• Add CustomShouldCompleteMapExample with local tests plus README and SAM template wiring.

Difference from the JS proposal

This is based on the same feature request as aws-durable-execution-sdk-js#701, but the Java API is intentionally a bit stricter and more explicit:

• The JS issue proposes shouldComplete: (status) => boolean; Java uses Function<CompletionStatus, CompletionDecision> so the custom condition decides both whether to complete and which ConcurrencyCompletionStatus to report.
• The JS proposal says shouldComplete takes precedence and threshold fields are ignored. Java makes shouldComplete mutually exclusive with minSuccessful, toleratedFailureCount, and toleratedFailurePercentage so ambiguous configs fail fast.
• The JS proposal introduces a single informational CUSTOM_COMPLETION reason and derives success/failure from item outcomes. Java does not add generic CUSTOM_COMPLETION; custom completion must choose CUSTOM_COMPLETION_SUCCEEDED or CUSTOM_COMPLETION_FAILED, and success is carried by the enum via completionStatus.isSucceeded().
• Java removes the separate succeeded flag from CompletionDecision; completed decisions must always provide a ConcurrencyCompletionStatus, and the status itself owns success semantics.
• Java fully relies on the custom shouldComplete result when custom completion is configured. It does not automatically convert all-items-completed into ALL_COMPLETED; callers that want an all-completed fallback can return that decision from their callback using status.allCompleted().
• Java exposes allItemsRegistered on CompletionStatus, in addition to the count fields, so callbacks can distinguish “all currently registered items are done” from “the caller has finished registering items”.
• Java validates null custom decisions at the concurrency operation evaluation point (canComplete) instead of wrapping the user callback inside CompletionConfig.

Testing

• mvn spotless:apply
• mvn -pl examples -am -Dtest=CustomShouldCompleteMapExampleTest -Dsurefire.failIfNoSpecifiedTests=false test
• mvn -pl sdk -Dtest=CompletionConfigTest,ConcurrencyCompletionStatusTest,MapResultTest,ParallelResultTest,ParallelConfigTest,ConcurrencyOperationTest,ParallelOperationTest test
• mvn -pl sdk,sdk-integration-tests -Dtest=MapIntegrationTest,ParallelIntegrationTest -Dsurefire.failIfNoSpecifiedTests=false test
• git diff --check
• git diff --cached --check