docs(adapter/sqs): PR #923 round-3 — drop stale buildBatchSendRecord doc + note residual edge

claude[bot] approved round-2; these are the two non-blocking nits it raised:
- Remove the stale first paragraph of buildBatchSendRecord's doc comment (it
  referenced a *sqsAPIError return that no longer exists and duplicated the
  accurate description that follows).
- Document the residual edge in the design doc: if attempt 1 commits and a
  concurrent SetQueueAttributes tightens a limit before the retry, the retry
  re-validates and reports the (already-stored) entry as failed — an
  inconsistent client view within the at-least-once contract, never a
  double-send. No code change.

No functional change.

Author: bootjp

adapter/sqs_messages_batch.go

@@ -403,10 +403,6 @@ func (s *SQSServer) resolveFreshFifoSnapshot(ctx context.Context, queueName stri
 	return meta, dedupID, delay, nil
 }
 
-// buildBatchSendRecord runs every per-entry validation a single
-// SendMessage would, but returns the *sqsAPIError so the batch path
-// can drop the entry into Failed[] instead of failing the whole
-// request.
 // buildBatchSendRecord builds one standard-queue batch entry's record. It splits
 // two concerns that must NOT be conflated:
 //

docs/design/2026_06_03_partial_dynamodb_onephase_dedup.md

@@ -357,7 +357,19 @@ every replica applying the same log entry.
     every attempt (`buildSendRecordWithIdentity`), so the retry overwrites the
     same keys idempotently. This needs **no** FSM probe / `PrevCommitTS` / gate —
     the keys become content-stable, so re-applying is a plain idempotent
-    overwrite. Tests: `adapter/sqs_batch_send_dedup_test.go`.
+    overwrite. The identity also pins `AvailableAtMillis` (vis-key input) and the
+    per-entry validation re-runs against the current meta on every attempt, so a
+    mid-retry `SetQueueAttributes` neither shifts the vis key (codex P2 round-1)
+    nor lets a now-too-large body through (codex P2 round-2). Tests:
+    `adapter/sqs_batch_send_dedup_test.go`.
+    - **Residual edge (within at-least-once, no action):** if attempt 1
+      *commits* (committed-but-conflicted) and a concurrent `SetQueueAttributes`
+      tightens a limit (e.g. lowers `MaximumMessageSize`) before the retry, the
+      retry's re-validation rejects the entry into `Failed[]` even though it is
+      already in the queue — an inconsistent client view (message stored, client
+      told it failed) but never a double-send. This is within the SQS
+      standard-queue at-least-once contract; distinguishing committed-vs-not
+      would need a dedup probe, which is out of proportion for this corner.
 
 ## Milestones