Improve EF Core / ILogger grouping

EF Core / ILogger grouping (issue [#3111]())

**Root cause:** When EF Core errors are logged via `ILogger` with a category like `Microsoft.EntityFrameworkCore.Database.Command`, every stack frame's module starts with `Microsoft`. That namespace is in `GetDefaultInAppExclude()` ([SentryOptions.cs:1959]()), so all frames get `InApp=false`.

When Sentry receives an event with **no** `InApp=true` frames, it falls back to grouping by the entire stack trace. Async/await machinery means the exact frames above the database call vary between requests (different thread-pool scheduling paths), so each event gets its own issue group — explosion of noise.

There's a second sub-problem: EF Core sometimes embeds its own stack trace inside the exception message string. Since Sentry uses the message as part of the issue title, that message is also ugly and misleading.

**What the SDK could do:**

* [Detect when all frames are `InApp=false` for events that come from a known logger category, and set an explicit `Fingerprint` based on logger category + exception type — grouping would then be stable and meaningful.]()
* [Strip the embedded stack trace from the EF Core exception message before capturing.]()
* There's no mechanism in the SDK today to do either of these. No fingerprinting or message-scrubbing logic exists for the ILogger path.