fix: populate sentry.sdk.name and sentry.sdk.version for console apps

[zkasuran]

Closes #5352

What changed and why

Structured logs and trace metrics from a plain console app were going out with no
sentry.sdk.name and no sentry.sdk.version attribute. The same code under
ASP.NET Core was fine. These attributes identify the SDK that produced the data, so
a whole class of apps was shipping logs and metrics that could not be attributed to
the .NET SDK.

Root cause: SentryAttributes.SetDefaultAttributes reads the SDK fields off the
SdkVersion it is handed:

if (sdk.Name is { } name)       { SetAttribute("sentry.sdk.name", name); }
if (sdk.Version is { } version) { SetAttribute("sentry.sdk.version", version); }

On the logs path (SentryLog.cs:153) and the metrics path
(SentryMetric.Factory.cs:23) the value passed in is scope.Sdk. Both sites try to
fall back with ?? SdkVersion.Instance, but that fallback is dead: Scope.Sdk is a
non-null auto-initialized property (Scope.cs:277, public SdkVersion Sdk { get; } = new();),
so scope?.Sdk ?? SdkVersion.Instance always resolves to scope.Sdk. In a console
app nothing populates that object, so Name and Version stay null and both guards
above are false. Framework integrations do not hit this: ASP.NET Core fills
scope.Sdk in SentryMiddleware.cs:257-258, so its logs carry the attributes.

The fix falls back per field to the populated SdkVersion.Instance at the one place
both paths share:

if ((sdk.Name ?? SdkVersion.Instance.Name) is { } name)
{
    SetAttribute("sentry.sdk.name", name);
}
if ((sdk.Version ?? SdkVersion.Instance.Version) is { } version)
{
    SetAttribute("sentry.sdk.version", version);
}

When an integration has already set scope.Sdk.Name, that value is non-null so the
?? short circuits and the integration still wins. The fallback only supplies a
value where the field would otherwise be null. SdkVersion.Instance is the same
object the envelope header uses, so logs and metrics now agree with the envelope.

Tests

• New: SentryLogTests.SetDefaultAttributes_EmptyScopeSdk_UsesSdkInstance builds a
  log with a fresh new Scope(options) (the console case) and asserts
  sentry.sdk.name == "sentry.dotnet" with a non-empty sentry.sdk.version.
• New: SentryMetricTests.SetDefaultAttributes_EmptySdk_UsesSdkInstance does the
  same for a metric built with new SdkVersion().
• Updated: SentryLogTests.WriteTo_Envelope_MinimalSerializedSentryLog and
  SentryMetricTests.WriteTo_Envelope_MinimalSerializedSentryMetric were pinning the
  old payload with no SDK attributes. They now include the SDK name and version,
  which is the correct serialized form after the fix.

The existing Protocol_Default_VerifyAttributes tests never caught this because they
pre-populate the Sdk before calling SetDefaultAttributes.

Verification

Verified locally in Docker (mcr.microsoft.com/dotnet/sdk:10.0.302, the exact SDK
pinned by global.json, host runs net10.0):

dotnet test test/Sentry.Tests/Sentry.Tests.csproj -f net10.0

• With the fix: Failed: 0, Passed: 2533, Skipped: 5, Total: 2538.
• Reverting only SentryAttributes.cs while keeping the tests: Failed: 4, Passed: 2529.
  The four failures are the two new tests plus the two corrected serialization tests,
  which reproduces the bug.
• dotnet format --verify-no-changes on the changed files: no changes.

Changelog

The commit and this PR lead with fix:, so craft categorizes it under Fixes at
release time. Per CONTRIBUTING.md I have not edited CHANGELOG.md by hand. Let me
know if you want a custom ### Changelog Entry with more detail than the title.

AI disclosure

AI assistance (Claude, Anthropic) was used to trace the root cause, write the fix and
the tests, then run the suite. I own the change, reviewed it and verified it locally
before submitting. Verified: the full Sentry.Tests suite on net10.0 (2533 passing,
0 failing); the bug reproduced by reverting only the source file (4 failing);
dotnet format --verify-no-changes clean on the changed files.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 74.75%. Comparing base (3fe027d) to head (9e08135).
⚠️ Report is 15 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #5483      +/-   ##
==========================================
+ Coverage   74.73%   74.75%   +0.01%     
==========================================
  Files         513      513              
  Lines       18744    18749       +5     
  Branches     3666     3667       +1     
==========================================
+ Hits        14009    14015       +6     
+ Misses       3863     3862       -1     
  Partials      872      872              

☔ View full report in Codecov by Harness.
📢 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.

[jamescrosswell]

Thanks @zkasuran - generally this looks good. I've made a couple of minor suggestions... just for housekeeping.

[zkasuran]

Thanks for the review @jamescrosswell. Both points are addressed in 8bba369. SetDefaultAttributes now moves the SDK name and version together (the scope's pair when set, otherwise Constants.SdkName with SdkVersion.Instance.Version) so they follow the same both-or-neither pattern as Enricher and Scope. The two regression tests now assert Constants.SdkName for the name.

Verified locally in Docker (mcr.microsoft.com/dotnet/sdk:10.0.302): dotnet test test/Sentry.Tests/Sentry.Tests.csproj -f net10.0 passes (0 failed, 2533 passed, 5 skipped) and dotnet format --verify-no-changes is clean on the changed files.

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

Want reviews to match your repository better? Bugbot Learning can learn team-specific rules from PR activity. A team admin can enable Learning in the Cursor dashboard.

^{Reviewed by Cursor Bugbot for commit 8bba369. Configure here.}

[jamescrosswell]

Awesome - thanks for the contribution @zkasuran ! 🙏🏻