Fix duplicate DeleteMessageBatchRequestEntry ids when SQS redelivers a message within one ack batch

[BK202503]

Summary

SqsAcknowledgementExecutor used MessageHeaderUtils.getId(message) — the Spring message id derived from the SQS messageId — as the DeleteMessageBatchRequestEntry.id. On a Standard queue, if the same SQS message is redelivered within one acknowledgement batch, two entries end up with the same id and AWS rejects the entire batch with BatchEntryIdsNotDistinctException. The reporter's analysis and full repro are in #1634.

Fix

Batch entry id is now a positional index into the snapshot list of messages passed to deleteMessageBatch. SQS only requires the id to be unique within a single request and doesn't otherwise interpret it, so a positional index is sufficient and keeps the mapping trivial.

Partial-failure correlation is updated accordingly: createPartialFailureException parses each BatchResultErrorEntry.id as an index into the ordered batch and buckets messages by index. If any returned id doesn't parse to a valid index — which shouldn't happen but preserves the previous defensive behaviour — the executor still returns the existing "cannot correlate all failure ids" case, treating every message as failed.

Tests

• New regression test: shouldUseUniqueBatchEntryIdsWhenMessageIdIsDuplicated — two mock messages sharing the same Spring message id (via MessagingMessageHeaders with an explicit shared UUID) but with distinct receipt handles → asserts the captured DeleteMessageBatchRequest entries have distinct ids and preserve both receipt handles in order. Fails on main (BatchEntryIdsNotDistinctException path exercised), passes with this change.
• Existing partial-failure test updated: shouldWrapPartialBatchFailure now uses id("0") (positional) instead of the message-header UUID.
• Full sqs module test suite: 634 tests, 0 failures, 0 errors, 5 skipped (./mvnw -pl spring-cloud-aws-sqs -am test — includes localstack integration tests).

Fixes #1634