chore: update Polyfill from 1.33.2 to 11.4.1

[jamescrosswell]

Summary

Updates Polyfill from 1.33.2 to 11.4.1 without changing Sentry's dependencies.

#4879 tried this upgrade but added System.Memory 4.6.3 as a top-level dependency for net462 and netstandard2.0, which is why #5006 was parked for the next major. Polyfill didn't need that dependency; it's a source-only package with no NuGet dependencies of its own. It was a workaround for SentrySdkCrashTests.CauseCrashInSeparateProcess failing on net48 once PolyStringInterpolation was enabled:

• With PolyStringInterpolation, SentrySdk.CauseCrash has to load System.Memory before it crashes.
• The test runs CrashableApp.exe from the Sentry.Tests output folder. That folder has System.Memory 4.6.3 (assembly 4.0.5.0), while Sentry.dll is compiled against 4.0.1.2 via System.Text.Json 8.0.5, and nothing redirects between the two.

This PR leaves PolyStringInterpolation off.

Changes

• Bump Polyfill in Sentry, Sentry.Analyzers and Sentry.Compiler.Extensions.
• Remove our AsReadOnly(IDictionary) polyfill. Polyfill now ships the same method, so the calls became ambiguous.
• Add a global using Polyfills; for non-.NET Core targets in src/ and test/ Directory.Build.props. Polyfill moved its extension methods into that namespace, and projects with access to Sentry's internals (DiagnosticSource, Serilog, OpenTelemetry, Sentry.Testing) use them.
• Set PolyfillNoWarnIncorrectVersion in the two Roslyn components. They only get System.Memory 4.5.4 from Roslyn, so Polyfill leaves out its span polyfills there and warns about it.
• Exclude Polyfill's ConditionalWeakTable.Remove(key, out value) polyfill. On net9.0 its TValue lacks the DynamicallyAccessedMembers annotation that ConditionalWeakTable requires, which fails Native AOT trim analysis with IL2091, and we don't use it. This is Polyfill's bug, still present on its main branch.

Compatibility

Compared with main:

• The nuspec dependency groups are identical.
• Sentry.dll's assembly references are identical on netstandard2.0 and 2.1. On net462 it also references System.Numerics, System.Xml and System.Xml.Linq, which ship with .NET Framework itself, not as NuGet packages.
• The API approval snapshots are unchanged.

So this shouldn't need to wait for the next major. The trade-off is assembly size; see the comment below.

Notes

• The net48 tests, including the crash test above, only run on Windows CI. I haven't verified them locally.
• sentry-unity: Unity assemblies that can see Sentry's internals will now also see Polyfill's Polyfills namespace, and could hit the same ambiguity or missing-using errors. I haven't checked this.

Closes #5006

🤖 Generated with Claude Code

[jamescrosswell]

Trade-off: assembly size

Polyfill compiles its whole API surface into the assembly as internal code. There's no option to include only the polyfills we actually use. Compared with the published Sentry 6.12.0 (Release builds):

TFM	6.12.0	This PR	Growth
net462	790 KB	1,078 KB	+287 KB (+36%)
netstandard2.0	781 KB	1,077 KB	+296 KB (+38%)
netstandard2.1	772 KB	1,036 KB	+264 KB (+34%)
net8.0	828 KB	989 KB	+161 KB (+19%)
net9.0	828 KB	920 KB	+92 KB (+11%)
net10.0	828 KB	896 KB	+68 KB (+8%)

Apps that trim, such as mobile and Native AOT apps, should drop most of the unused polyfill code. Desktop and .NET Framework apps ship all of it.

What we get for it: one fewer hand-written polyfill today, plus access to newer polyfilled APIs, e.g. the ArgumentExceptions follow-up in #4982.

@ric-oliv Is roughly 290 KB on the .NET Framework and netstandard targets, and 70–160 KB on net8–10, an acceptable price for that? If not, staying on 1.33.2 costs us nothing functionally.

[ric-oliv]

40% more size for no return... I'd rather not bring it in at this point 🤔

And my agent also has some concerns about how it will behave on older integrations such as netstandard2.0 and net462, that it can crash in specific scenarios.

Probably not worth the effort right now?

[jamescrosswell]

Won't do - increased size and limited benefit.