[Gitflow] Merge master into develop

Oops, we forgot this when moving the stuff from utils to core. The
canary test workflow only kept the utils build in cache, which lead to
this failing - now, we just keep all build output in cache, to be on the
safe side...

see:
https://github.com/getsentry/sentry-javascript/actions/runs/11971041974

…stData` (#14430)

…14433)

As Nuxt generates and keeps server source maps per default, only the
source maps in the public folder are deleted after uploading them to
Sentry.

Dev tools sometimes try to access source maps. This filter makes sure
this error is not reported in Sentry as it adds noise to the data.

This adds node & browser integration tests to demonstrate the current
behavior of "trace propagation" based on the current scope.

It shows that the behavior is not really consistent and we should
probably adjust it, but for now this PR does no changes.

## Browser

In browser, the propagation context of the current scope is always
picked up. This means that if you call `startSpan` multiple times in the
root, both started spans will have the same trace ID, and possibly the
same `parentSpanId` if there was an incoming trace.

## Node

In node, the propagation context is ignored for the root context. So in
the root, started spans will have different traces, and will also ignore
parentSpanId (which is only theoretical, there will never really be a
parentSpanId on the root scope in node, realistically).

Outside of the root (so e.g. within any route handler, or even any
`withScope` call), the behavior is the same as in browser - any started
spans will share the same trace ID/parent span ID.

## What should we take away from this?

In node, I would align the behavior to ignore the trace ID when we have
no incoming trace (so no parentSpanId), and always use the traceId &
parentSpanId if there is a parentSpanId on the scope (even the root
scope, to be consistent).

In browser, we cannot make this change because we rely on this behavior
for the extended traces after pageload/navigation spans have ended.

…her than through the `vueIntegration`'s `tracingOptions` option (#14385)

This PR adds the external contributor to the CHANGELOG.md file, so that
they are credited for their contribution. See #14440

Co-authored-by: chargome <[email protected]>

…eFifoCache` (#14434)

Ref: #14267

From my investigation, redis does not actually support arrays/nested
arrays for keys and ioredis is wrapping thinly over redis functions, but
otel has `any[]` as one of their possible values for command line
arguments so I opted for inlining the implementation and adding a note
to use `Array.flat` in v9.

We apparently disabled the no-optional-chaining rule in browser-utils,
which lead to us including this polyfill. Properly enforcing this rule
should (hopefully?) reduce bundle size a bit.

This PR updates & streamlines our handling of certain `undefined`
options:

First, we do not want to differentiate anymore between options being
unset and set to `undefined` - the resulting behavior should be the
same. This especially applies to the tracing options `tracesSampleRate`,
`tracesSampler` and `enableTracing` - if any of those is set to
`undefined`, `hasEnabledTracing()` will be true and certain things will
happen.

In v9, we want to change this so that `undefined` will also result in
`hasEnabledTracing() === false`. We'll warn if we encounter such a
scenario.

Another related thing this PR does is streamline how we handle falsy
values for `environment`, `release` and `dist` on an event. Today, we go
out of our way to check if the properties are set and only update them
accordingly. However, fasly values do not make sense for these fields
anyhow, so we can streamline this a bit and simply check for truthiness
to determine if we want to use event, option, or default values.

Closes #14261

Streamline some debug logs, esp. also removing some debug logs around
browser metrics, in favor of just having a generic log when we add
measurements.

Backfills items to the draft migration guide for v9 that we missed

- #14433
- #14454

As a first step for
#12385, I looked
though our current implementations, and tried to streamline this. We
have a bunch of somewhat duplicate code there that handles sentry-trace
& baggage headers _mostly_ the same but not _fully_ the same, as well as
relatedly the DSC.

To streamline this, I added some new methods in core:

* `getTraceData` already exists, but was extended to also allow to pass
a specific `span` to it. I updated some code to use this method that
hasn't used it before, and also added some more tests - also around the
ACS and the otel-specific implementation for this.
* For this and edge cases, there are new primitives
`getDynamicSamplingContextFromScope` and `getTraceContextFromScope`
which handle picking these things from given scope etc.

While working on this, I also noticed that `captureCheckIn` in
ServerRuntimeClient was actually not properly working in Node (OTEL), as
it relied on the core way of scope-span coupling. So I also updated this
to actually work as expected.

… nitro (#14480)

Noticed that our e2e tests are not actually using nitro 2.10 despite
being on the latest nuxt version:
https://github.com/getsentry/sentry-javascript/actions/runs/12028119465/job/33531969920#step:13:196

This fixes it.

This PR adds a minimum required version for the Nuxt SDK. Version 3.7.0
was selected because this version adds the possibility to set client
source maps to `'hidden'` ([PR
here](nuxt/nuxt#22787)).

However, as the SDK relies on other versions as well (see below, at the
bottom), those packages need to be manually bumped (in case the
lock-file is not updated yet). **Nuxt 3.7.0** at least supports the
correct version range:
["nitropack":
"^2.6.1"](https://github.com/nuxt/nuxt/blob/v3.7.0/packages/nuxt/package.json#L84)
["ofetch":
"^1.3.3"](https://github.com/nuxt/nuxt/blob/v3.7.0/packages/nuxt/package.json#L87)

Above **Nuxt v3.14.0**, everything works out of the box, as the versions
are already updated:
["nitropack":
"^2.10.2"](https://github.com/nuxt/nuxt/blob/v3.14.0/packages/nuxt/package.json#L97)
["ofetch":
"^1.4.1"](https://github.com/nuxt/nuxt/blob/v3.14.0/packages/nuxt/package.json#L100)

#### Minimum versions, the SDK relies on:
- `nitropack` 2.10.0: for the correct peerDependency of `@vercel/nft`
- `ofetch` 1.4.0: for being able to patch `$fetch`

This PR drops the validation for baggage content. We didn't do this for
browser previously, only for node, but it adds bundle size and does not
appear too important.

I left the trace header validation in for now, we may also drop this but
it is smaller and I guess also more important to us...?

…erHooks.exclude` (#14486)

Co-authored-by: Luca Forstner <[email protected]>