build: enable CA2007 enforcement via nested src/.editorconfig

[jamescrosswell]

Summary

Move ConfigureAwait(false) enforcement (CA2007) from the legacy src/CodeAnalysis.ruleset to a nested src/.editorconfig.

The ruleset file no longer reliably enables CA2007 with current .NET SDKs (CA2007 is disabled by default in modern .NET analyzers, and <CodeAnalysisRuleSet> only overrides severity for rules that are already active). As a result, the rule only fired in CI Release builds and was silently ignored locally — both in Rider and with dotnet build — the regression reported in #2308.

Using dotnet_diagnostic.CA2007.severity = error inside a nested editorconfig under /src has two advantages over the previous setup:

• It correctly activates analyzer rules that are disabled by default, so violations fail locally and in CI
• It scopes the rule to library code only. Tests, samples, benchmarks and integration-test projects are unaffected, where calling ConfigureAwait(false) is unnecessary noise.

Verification

Tested locally on macOS:

• Clean build of src/Sentry/Sentry.csproj in Debug → 0 errors.
• Temporarily replaced await sentryTask.ConfigureAwait(false); with await sentryTask; in SpotlightHttpTransport.cs → build fails with:

  error CA2007: Consider calling ConfigureAwait on the awaited task
  

  ...across all target frameworks (net8.0, net9.0, net10.0). Reverted before commit.
• Built test/Sentry.Tests/Sentry.Tests.csproj with its existing await client.GetAsync(...); calls (no ConfigureAwait) → 0 CA2007 errors, confirming the rule is correctly scoped to /src only.

Closes #2308

#skip-changelog

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 74.13%. Comparing base (a9cb3b2) to head (0b8dba2).
⚠️ Report is 11 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #5230      +/-   ##
==========================================
+ Coverage   74.12%   74.13%   +0.01%     
==========================================
  Files         508      508              
  Lines       18282    18282              
  Branches     3574     3574              
==========================================
+ Hits        13551    13553       +2     
+ Misses       3861     3860       -1     
+ Partials      870      869       -1     

☔ 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.

[Flash0ver]

One optional comment.

[Flash0ver]

question: .editorconfig vs .globalconfig

I'm wondering, which file is better here:

• .editorconfig
• .globalconfig

To me, .editorconfig is more for style choices,
and .globalconfig is more for code quality rules.

The difference on a "content level" is that (unlike .editorconfig), .globalconfig does not have a language section (e.g. [*.cs]).

See also https://learn.microsoft.com/dotnet/fundamentals/code-analysis/configuration-files#global-analyzerconfig

But ... to be fair ... this might be just total bikeshedding from my end, and is more of a "stylistic" choice rather than a "functional" choice.

I just wanted to raise awareness that there is also a .globalconfig option we could use.

[jamescrosswell]

Let's change if it ever causes us issues further down the road. For the time being, I think this does what we want and we can move on to other stuff.