Logs and metrics are not attributed to the wrapping SDK (e.g. Google Cloud Functions, gRPC)

Split out of a review thread on #5504: https://github.com/getsentry/sentry-dotnet/pull/5504/changes#r3842135440

## Problem

Some integrations wrap ASP.NET Core and take over the SDK name so events are attributed to the wrapper rather than to `sentry.dotnet.aspnetcore`. They do this with an `ISentryEventProcessor`, which by definition only ever sees a `SentryEvent`. Logs and metrics are not events, so they never get the override and go out labelled as the *inner* SDK.

Concretely, in a Google Cloud Function:

| Signal | `sdk.name` |
| --- | --- |
| Events | `sentry.dotnet.google-cloud-function` ✅ |
| Logs | `sentry.dotnet.aspnetcore` ❌ |
| Metrics | `sentry.dotnet.aspnetcore` ❌ |

## Why the three signals disagree

Each signal takes its `SdkVersion` from a different place:

- **Events** — the event-processor chain. [`SentryGoogleCloudFunctionEventProcessor`](https://github.com/getsentry/sentry-dotnet/blob/main/src/Sentry.Google.Cloud.Functions/SentryStartup.cs#L97-L118) rewrites `@event.Sdk.Name`.
- **Logs** — the `SdkVersion` baked into the registered `ILoggerProvider`. `SentryStartup` registers [`SentryAspNetCoreStructuredLoggerProvider`](https://github.com/getsentry/sentry-dotnet/blob/main/src/Sentry.AspNetCore/SentryAspNetCoreStructuredLoggerProvider.cs), whose `CreateSdkVersion()` hardcodes `Sentry.AspNetCore`'s `Constants.SdkName`.
- **Metrics** — `scope?.Sdk`, and [`SentryMiddleware`](https://github.com/getsentry/sentry-dotnet/blob/main/src/Sentry.AspNetCore/SentryMiddleware.cs#L257) sets `scope.Sdk.Name = "sentry.dotnet.aspnetcore"`.

So an integration that only overrides the event path silently gets the other two wrong.

## Affected

- **`Sentry.Google.Cloud.Functions`** — `sentry.dotnet.google-cloud-function`
- **`Sentry.AspNetCore.Grpc`** — `sentry.dotnet.aspnetcore.grpc` ([same shape](https://github.com/getsentry/sentry-dotnet/blob/main/src/Sentry.AspNetCore.Grpc/SentryBuilderExtensions.cs#L31-L52))
- **`Sentry.AspNet`** — `sentry.dotnet.aspnet`; only reachable if the app also wires up a logging integration, so lower impact

**Not** affected: `Sentry.Maui` registers its own `SentryMauiStructuredLoggerProvider`, and the Serilog/NLog/log4net sinks stamp their own SDK on each log directly — those are the patterns that get it right.

## Not a regression, but newly visible

This has been true since structured logs shipped; it only affected people who opted in with `EnableLogs = true`. #5504 makes logs on by default, so it now affects everyone using these integrations. It surfaced there as a test change — `SentryIntegrationTest_CaptureUnhandledException` asserted the wrapper SDK name on *every* outbound request and had to be narrowed to the envelopes carrying the error, because the log envelope legitimately does not carry it.

## Suggested direction

Rather than each wrapper patching three separate paths, it would be worth giving them one place to declare the SDK identity that events, logs and metrics all read from. Failing that, the two ASP.NET Core wrappers need their own `ILoggerProvider` subclass (as MAUI has) plus something equivalent for the scope's `Sdk`.

Start with Sentry.Google.Cloud.Functions/SentryStartup.cs, Sentry.AspNetCore/SentryAspNetCoreStructuredLoggerProvider.cs, and Sentry.AspNetCore/SentryMiddleware.cs to trace how events, logs, and metrics obtain their SDK identity. Compare the affected Google Cloud Functions and ASP.NET Core gRPC integration paths, then run SentryIntegrationTest_CaptureUnhandledException and related integration tests. Done means all three signals use the wrapping SDK name consistently without breaking unaffected integrations.

Written by the indexing model from the issue text.