feat(aws-lambda): Add queue.process spans for messaging triggers - #8223

)

### Description

Since #8137, #8142, and #8145, boto3 puts `sentry-trace` in SQS and SNS
message attributes, but nothing reads it on the Lambda side. This PR is
the smallest change that closes the loop for SQS- and SNS-triggered
functions. The Lambda integration now reads `sentry-trace` from each
record and adds a `message_origin` link from the invocation span to each
distinct producer span. This matches what the boto3 `ReceiveMessage`
span already does. Messages never become the invocation's parent.

It reads:
- SQS records: `messageAttributes["sentry-trace"].stringValue`
- SNS records: `Sns.MessageAttributes["sentry-trace"].Value`
- SNS → SQS without raw message delivery: the SNS envelope in the SQS
`body`, the same as boto3 does

Links are deduplicated, because a batch send gives many messages the
same producer span, and capped at 128, OTel's default, because Lambda
can deliver up to 10,000 SQS messages at once.

**Scope.** This is intentionally kept separate from the stretch stack.
It doesn't add `faas.trigger` (#8222) or `queue.process` spans (#8223),
and it doesn't touch `messaging.batch.message_count` (#8229). The
invocation span is otherwise unchanged. Synchronous `Invoke` propagation
through `ClientContext` is #8221. That PR changes the `continue_trace`
call and this one only adds `links=`, so the two are independent.

The link-building code repeats boto3's `_message_link` in a Lambda-event
shape: Lambda records use `messageAttributes` / `stringValue` / `body`,
while the boto3 response uses `MessageAttributes` / `StringValue` /
`Body`. Importing from the boto3 integration would make `aws_lambda`
depend on botocore.

**Testing.** `test_producer_links` sends SQS, SNS, and SNS-to-SQS events
to `BasicOkSpanStreaming`. It asserts the segment span's `links` and
that the segment span has no parent. It passes in CI's Cloud (Lambda)
jobs, and `ruff` and `mypy sentry_sdk` pass. `codecov/patch` is red
because the Lambda tests run in `sam local` containers, so their
coverage isn't counted.

#### Issues
* Part of #8081

<!-- junior-request-attribution:start -->
via **webb**, @sentrivana.
<!-- junior-request-attribution:end -->

<!-- junior-session-footer:start -->
<!-- junior-conversation-id:slack%3AC09M26BC6A1%3A1794211222.463239 -->

--

[View
Session](https://junior-prod.sentry.dev/conversations/slack%3AC09M26BC6A1%3A1794211222.463239)
[[Sentry]](https://sentry.sentry.io/explore/conversations/slack%3AC09M26BC6A1%3A1794211222.463239/?project=4510944073809921)

<!-- junior-session-footer:end -->

---------

Co-authored-by: sentry-junior[bot] <264270552+sentry-junior[bot]@users.noreply.github.com>
Co-authored-by: Alexander Webb <alexander.webb@sentry.io>
Co-authored-by: Ivana Kellyer <131587164+sentrivana@users.noreply.github.com>

… span (#8229)

### Description

The Lambda span set `messaging.batch.message_count` to `1` for every
event that isn't a list, and to `len(event)` for a top-level list. An
SQS or SNS delivery is a dict with `Records`, so a batch of 10 messages
reported 1. HTTP calls and direct invocations reported a batch they
don't have.

This PR removes the attribute from the Lambda span. The count belongs on
messaging spans, as in the OTel messaging conventions:
- boto3 `ReceiveMessage` and batch-send spans already set it (#8137,
#8142).
- For SQS/SNS-triggered Lambdas, the `queue.process` span in #8223 sets
it.

The JS SDK doesn't set it on the Lambda span either. The attribute was
added in 3.0 (#7941) and never shipped in 2.x, so no released behavior
changes.

Replaces #8219 (same commits). GitHub never ran CI on #8219.

**Note for review:** this is narrower than PY-3015, which asks to keep
the attribute for SQS/SNS deliveries. @alexander-alderman-webb, please
confirm that's OK.

#### Issues
* resolves: PY-3015

<!-- junior-request-attribution:start -->
via @dingsdax.
<!-- junior-request-attribution:end -->

<!-- junior-session-footer:start -->
<!-- junior-conversation-id:slack%3AC0C9X9V5NMT%3A1793904671.980379 -->

--

[View
Session](https://junior-prod.sentry.dev/conversations/slack%3AC0C9X9V5NMT%3A1793904671.980379)
[[Sentry]](https://sentry.sentry.io/explore/conversations/slack%3AC0C9X9V5NMT%3A1793904671.980379/?project=4510944073809921)

<!-- junior-session-footer:end -->

---------

Co-authored-by: sentry-junior[bot] <264270552+sentry-junior[bot]@users.noreply.github.com>
Co-authored-by: Johannes Daxböck <114897+dingsdax@users.noreply.github.com>

### Description

Sets `faas.trigger` on the Lambda span based on the shape of the
delivered event:
- `http`: API Gateway REST/HTTP, function URLs, ALB, CloudFront, AppSync
- `pubsub`: SQS, SNS, Kinesis, Kafka, MQ, SES, EventBridge
- `datasource`: S3, DynamoDB Streams, DocumentDB
- `timer`: EventBridge schedules
- `other`: anything else

The trigger is read from the event envelope, never from its payload.
`test_trigger` has one case per code path. Other event sources use the
same lookup table, so they have no extra cases.

This PR doesn't touch `messaging.batch.message_count`. That change is in
#8229.

This is Pablo's code from `pablo/aws-lambda-trigger`, without his batch
counting for the invocation span. It's the second of three stacked PRs
(#8221 → this → #8223).

#### Issues
* resolves: PY-3018 (`faas.trigger` part; the per-source attributes in
the issue aren't in this PR)
* Part of #8081

<!-- junior-request-attribution:start -->
via @dingsdax.
<!-- junior-request-attribution:end -->

<!-- junior-session-footer:start -->
<!-- junior-conversation-id:slack%3AC0C9X9V5NMT%3A1793904671.980379 -->

--

[View
Session](https://junior-prod.sentry.dev/conversations/slack%3AC0C9X9V5NMT%3A1793904671.980379)
[[Sentry]](https://sentry.sentry.io/explore/conversations/slack%3AC0C9X9V5NMT%3A1793904671.980379/?project=4510944073809921)

<!-- junior-session-footer:end -->

---------

Co-authored-by: Pablo Deputter <pablo.deputter@sentry.io>
Co-authored-by: Pablo Deputter <71842639+pabloDeputter@users.noreply.github.com>
Co-authored-by: sentry-junior[bot] <264270552+sentry-junior[bot]@users.noreply.github.com>
Co-authored-by: Johannes Daxböck <114897+dingsdax@users.noreply.github.com>