feat(serilog): support restrictedToMinimumLevel when configuring Serilog in code

[jamescrosswell]

Summary

Fixes #4957

• Added RestrictedToMinimumLevel and LevelSwitch options to SentrySerilogOptions, plus matching restrictedToMinimumLevel and levelSwitch parameters on the two parameterized Sentry() extension method overloads on LoggerSinkConfiguration
• These are passed through to Serilog's underlying Sink() call, enabling per-sink minimum level filtering to be set in code
• Previously, per-sink minimum levels could only be configured via appsettings.json; this change unblocks MAUI users who configure Serilog in code

Usage

.WriteTo.Sentry(o =>
{
    o.MinimumBreadcrumbLevel = LogEventLevel.Debug;
    o.MinimumEventLevel = LogEventLevel.Error;
    // Only Warning and higher reach the Sentry sink
    o.RestrictedToMinimumLevel = LogEventLevel.Warning;
})

Docs

• docs(dotnet): Document Serilog per-sink minimum level options sentry-docs#18740

🤖 Generated with Claude Code

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 74.13%. Comparing base (32a55e3) to head (3516b83).
⚠️ Report is 15 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #5181      +/-   ##
==========================================
+ Coverage   74.06%   74.13%   +0.07%     
==========================================
  Files         501      506       +5     
  Lines       18113    18255     +142     
  Branches     3521     3564      +43     
==========================================
+ Hits        13415    13533     +118     
- Misses       3838     3852      +14     
- Partials      860      870      +10     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[sentry-warden]

Adding optional parameters to public Sentry() overloads is a binary-breaking change

Adding new optional parameters (restrictedToMinimumLevel, levelSwitch) to the existing public Sentry() extension methods changes their metadata signatures. While source-compatible, this is binary-breaking in .NET: consumers compiled against a previous version of Sentry.Serilog will get a MissingMethodException at runtime until they recompile. For a public library this is an API contract change that warrants senior engineer review and, ideally, preservation of the prior signatures via additional overloads instead of in-place parameter additions.

Verification

Read src/Sentry.Serilog/SentrySinkExtensions.cs and confirmed the two affected overloads (lines 86-113 and 180-187) had new optional parameters appended rather than being introduced as new overloads. Verified that the API approval snapshot reflects the same signature change at lines 24 and 49-53 of the .verified.txt hunk. .NET's binding to optional parameters is resolved at the call site at compile time, so adding optional parameters changes the method's metadata token and breaks binary compatibility, even though source compiles unchanged.

Identified by Warden code-review · PB4-XBA

[jamescrosswell]

@Flash0ver I'd rather go with a binary breaking change here (it's source compatible). The signatures get really messy if we try to add overloads (there are domino effects).

I don't think there are many people swapping out the Sentry dll without recompiling their apps when they upgrade (I'd venture to say probably none)... and accessing functionality like this via reflection also seems highly improbable.

How do you feel about that?