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

[jamescrosswell]

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 rewrites @event.Sdk.Name.
• Logs — the SdkVersion baked into the registered ILoggerProvider. SentryStartup registers SentryAspNetCoreStructuredLoggerProvider, whose CreateSdkVersion() hardcodes Sentry.AspNetCore's Constants.SdkName.
• Metrics — scope?.Sdk, and SentryMiddleware 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)
• 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.

[linear-code]

NET-792