Build AWS e2e example app with blog scenarios #8206

Small SAM app in sentry-python under scripts/aws/e2e/, next to scripts/aws/aws-deploy-local-layer.sh. It's the manual end-to-end check for the 3.0 queue work and the basis for the blog post: API Gateway → intake Lambda → SQS (with DLQ) → worker Lambda → Bedrock Converse/ConverseStream → DynamoDB. A verify script checks the resulting traces through the Sentry API and prints pass/fail plus a trace link per scenario.

• Scenarios:
  • happy: send one ticket. The request shows queue.publish. The worker shows a Bedrock Converse span (gen_ai.chat) with prompt, response and tokens.
  • stream: the same, but the worker uses ConverseStream. The Bedrock span has the streamed response and tokens.
  • poison: the worker fails on purpose. Sentry shows an error for each try. After 3 tries (default), SQS moves the message to the dead-letter queue (DLQ).
  • batch: send 10 tickets (default, SQS batch max) with one SendMessageBatch call. The queue.publish span shows a message count of 10.
  • Stretch only: in all scenarios, the worker gets a queue.process span that links to the request trace. Poison and batch only show the async story if feat(aws-lambda): Add queue.process spans for messaging triggers #8083 lands.
• Why in sentry-python rather than a separate repo? No new repo to request, the app is versioned with the code it checks, and agents find it next to the integration. It stays outside tests/, so tox and CI never try to reach AWS. The folder is self-contained, so a blog article can link to it directly.
• The layer ARN is a template parameter: a branch build from aws-deploy-local-layer.sh, or the public layer.
• Possible default: eu-central-1, Nova Micro via eu.amazon.nova-micro-v1:0. Run by hand; no CI.