Our `http.client` span instrumentations currently treat data URLs (blobs
or base64 encoded data) like regular raw URLs. While this is in general
fine, the problem is that this leads to incredibly long span names and
attribute values, especially because the URL is sent in up to three
different attributes per span. This makes Relay reject the the sent
events due to exceeding size limits.

This patch extracts the already existing stack trace URL
sanitization logic for data URLs and apply it to `http.client` spans and
attributes

Upgrades `@prisma/instrumentation` from `6.19.0` to `7.2.0`. The
instrumentation should be backwards compatible with v5 and v6 (we have
integration tests for v5 and v6). I also added integration tests for v7.

Closes: #18876

Signed-off-by: dependabot[bot] <support@github.com>
Co-authored-by: Tim Fish <tim@timfish.uk>
Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
Co-authored-by: Abdelrahman Awad <abdelrahman.awad@sentry.io>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Co-authored-by: JPeer264 <jan.peer@sentry.io>
Co-authored-by: Lukas Stracke <lukas.stracke@sentry.io>

[Gitflow] Merge master into develop

…#18906)

**Changes**

- This simplifies AI message truncation to always keep only the last
message and truncate it if needed. Previously we dropped oldest messages
one by one until we fit within the limit.
- Set embeddings input as a separate attribute `gen_ai.embeddings.input`
and do not truncate that.
- Also added support for truncating plain string arrays. Not sure if we
need that at the moment, since we no longer truncate embeddings, but
shouldn't hurt.

**Test Updates**

- Updated all node integration and unit tests to work with the new
logic.
- Extended the node integration suite to always test the two main
scenarios (keep the large message and then either truncate if the last
message is large or leave it as is if it is small).
- Removed the embeddings truncation tests and instead added a new
embeddings scenario that checks that embeddings inputs are all kept
(even if an array with multiple entries is passed).

Closes #18916

This PR adds automatic instrumentation for global request and function
middleware in TanStack Start applications.

**Overview**

The sentryTanstackStart Vite plugin now automatically wraps
requestMiddleware and functionMiddleware arrays in `createStart()` with
Sentry instrumentation. This is done via a source code transformation
during the build that converts:

```
createStart({
  requestMiddleware: [myMiddleware],
  functionMiddleware: [anotherMiddleware],
});
```

into:

```
import { wrapMiddlewaresWithSentry } from '@sentry/tanstackstart-react';

createStart({
  requestMiddleware: wrapMiddlewaresWithSentry({ myMiddleware }),
  functionMiddleware: wrapMiddlewaresWithSentry({ anotherMiddleware }),
});
```

**Usage**

Auto-instrumentation is enabled by default. To explicitly disable it:

```
// vite.config.ts
import { sentryTanstackStart } from '@sentry/tanstackstart-react';

export default defineConfig({
  plugins: [
    sentryTanstackStart({
      org: 'your-org',
      project: 'your-project',
      autoInstrumentMiddleware: false, // Disable auto-instrumentation
    }),
  ],
});
```

This should give users flexibility in case things go wrong.

**Implementation Details**

- Uses a regex-based approach to transform source files containing
`createStart()`
- Skips transformation if the user has already manually wrapped
middlewares with `wrapMiddlewaresWithSentry`
- Only handles simple identifier arrays (e.g., [foo, bar]), not complex
expressions

**Testing**

- Updated E2E tests to use auto-instrumentation for global middleware
- Updated unit tests for the `sentryTanstackStart` plugin
- Added unit tests for `autoInstrumentMiddleware`

**Follow-ups**

Future PRs will add support for non-global request/function middleware.
This PR focuses on global middleware to make it a bit easier to review.
I also want to give users a bit more control by allowing them to disable
auto-instrumentation on a file-level, but this doesn't make sense yet
since the current implementation only patches a single file anyways.

Closes #18845