Platform: SQS infrastructure for task worker mode (#34)

[I-am-nothing]

Summary

Platform-side infrastructure required for the ECS task worker mode shipped in SDK issue #34. The SDK publishes to a per-module SQS queue; the platform must provision it, scope IAM, and distribute the HMAC signing key.

What the SDK expects (from merged PRs #68, #69, #70, #71)

1. SQS queue per module — standard queue, SSE-KMS encryption, DLQ attached with redrive policy matching each task's declared `maxRetries` from the manifest.

2. IAM scoping — `sqs:SendMessage` on the module's queue granted to the module's Lambda execution role only. ECS task worker role gets `sqs:ReceiveMessage` + `sqs:DeleteMessage` + `sqs:ChangeMessageVisibility` only. Never `*`.

3. Signing key generation — `MS_TASK_SIGNING_KEY` must be ≥32 bytes, CSPRNG-generated. Distributed to both Lambda (signer) and ECS task role (verifier) via the same secure channel as `MS_INTERNAL_SECRET`. Rotation story TBD.

4. Queue URL injection — `MS_TASK_QUEUE_URL` set in both Lambda and ECS task definitions at deploy time.

5. DLQ access — operators need visibility into DLQ contents for poison-pill debugging.

Files / systems affected

• Platform provisioning (Terraform / CDK / whatever the platform uses)
• IAM policy templates
• Secret distribution pipeline (for `MS_TASK_SIGNING_KEY`)
• DLQ monitoring dashboards

Blocking

• ECS task worker deployments cannot go live without this.

Origin

Documented in PR #68-#71 descriptions + plan file; never filed as a trackable platform issue.

[I-am-nothing]

Tracking the platform-side SQS provisioning in api-platform#78 (a second consumer — account-closure orchestrator — needs the same infra). When #78 lands, the queues are available for ms.RunTask wiring.