chore: provision (or remove) the SQS queue and Lambda event source mapping for async purchase execution #399

Summary

internal/server/lambda.go's handleLambdaSQSEvent implements SQS-driven async purchase execution (AsyncMessage / HandleSQSMessage / purchase.Manager.ProcessMessage), and PR #382 fixed its partial-batch-failure handling. But this repository's IaC provisions no SQS queue and no Lambda event source mapping at all.

Confirmed via a full-repo search (rg, not the ugrep-shadowed grep wrapper) for aws_sqs_queue, AWS::SQS::Queue, EventSourceMapping, and batch_size across terraform/, cloudformation/, iac/, and arm/: zero hits in every case, including inside terraform/modules/compute/aws/lambda/ where the Lambda function itself is defined. This matches the audit's own caveat still in the tree at docs/audits/codebase-audit-2026-09-02.md:6025, which called the redelivery-to-DLQ scenario "PLAUSIBLE" rather than confirmed for exactly this reason.

PR #382 added SQS_REPORT_BATCH_ITEM_FAILURES (default false, fail closed) so the partial-batch-item-failure response is never emitted until an operator confirms the corresponding Terraform setting is live -- but that only guards against a worse outcome if/when the queue exists. It does not answer whether the async SQS purchase-execution path is meant to be live in production at all.

Two ways to close this

1. Provision the queue. Add an aws_sqs_queue (+ DLQ with a redrive_policy, sane maxReceiveCount, visibility_timeout comfortably above the Lambda timeout) and aws_lambda_event_source_mapping with function_response_types = ["ReportBatchItemFailures"], plus the IAM grant letting the Lambda poll it (sqs:ReceiveMessage, sqs:DeleteMessage, sqs:GetQueueAttributes scoped to the queue ARN) and whatever publishes to it (sqs:SendMessage from the approve/execute/cancel code paths that currently build AsyncMessage payloads -- worth checking whether anything actually calls SendMessage today, since no queue URL env var reference turned up either). Once live, flip SQS_REPORT_BATCH_ITEM_FAILURES=true.
2. Remove the dead path. If async SQS purchase execution was never wired into production (this repo shipping no queue at all is a strong signal), handleLambdaSQSEvent, HandleSQSMessage, AsyncMessage, and purchase.Manager.ProcessMessage are dead code that should be removed rather than carried forward and re-audited indefinitely.

Either way, resolving this removes the "PLAUSIBLE, could not establish from source" uncertainty the original audit flagged.

Related

• PR fix(server): SQS batch failure redelivers already-processed purchase messages (no BatchItemFailures) #382 (closes fix(server): SQS batch failure redelivers already-processed purchase messages (no BatchItemFailures) #108): the Go-side partial-batch-failure fix and the SQS_REPORT_BATCH_ITEM_FAILURES fail-closed flag.
• docs/audits/codebase-audit-2026-09-02.md:6025