feat(windows): add WINE and Proton runtime context

[GtechGovind]

Closes #1004.

Summary

• detect WINE through the exports exposed by ntdll.dll
• detect the precise Proton compatibility tool from Steam config_info and version metadata
• report Wine, Proton, Proton Experimental, Proton Hotfix, GE-Proton, and custom variants through a typed runtime context
• avoid adding the context on native Windows or when the required WINE version export is unavailable
• add unit coverage for runtime classification and missing metadata

Validation

• make test-unit
• clang-format verification via scripts/check-clang-format.py

Notes

The Proton lookup follows the reference implementation in getsentry/sentry-godot#591 while keeping this PR focused on compatibility runtime detection. Broader SteamOS, device, and host OS enrichment can be added separately.

[jpnurmi]

Thank you for the contribution, @GtechGovind!

While this implements the old minimal Wine metadata proposed in #1004, there's now a more recent and comprehensive reference implementation in sentry-godot:

• feat: SteamOS and Wine/Proton support sentry-godot#591

@limbonaut What do you think? Should we rather port the Godot implementation?

[codecov]

Codecov Report

❌ Patch coverage is 80.48780% with 8 lines in your changes missing coverage. Please review.
✅ Project coverage is 74.33%. Comparing base (38fb099) to head (7f8e655).

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #1995      +/-   ##
==========================================
+ Coverage   74.31%   74.33%   +0.02%     
==========================================
  Files         104      104              
  Lines       25738    25779      +41     
  Branches     4648     4656       +8     
==========================================
+ Hits        19126    19164      +38     
+ Misses       5305     5304       -1     
- Partials     1307     1311       +4     

🚀 New features to boost your workflow:

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

[limbonaut]

The problem with the bare Wine context from ntdll is that it's misleading with the Proton distributions. The proton builds report wine-10.0. And while Proton is based on Wine, this misleads on which actual Wine/Proton is being used.

I see no reason why we shouldn't move Godot's implementation into native, maybe even device/OS detection too. Currently, we maintain parallel implementations in Godot and Unreal. Unity would probably need a separate treatment though, since it's based primarily on the .NET SDK. I think it would be best if we also add this in the .NET SDK.

What we do in Godot:

• Fill runtime context with the proton/wine info.
• Detect SteamOS, Bazzite and Linux distros and fill the os context.
• Detect SteamDeck skews and fill the device context.
• Detect Steam environment and add steam: true tag.

What else can we do (that I didn't get to):

• Detect native Steam containers (scout, sniper, etc), fill runtime and report the actual host OS.

One contention point: we only have one runtime context, and both Wine and .NET compete for it (correction: specs indicate that we may add several runtime contexts). We can name it "compatibility" or "wine" context with the type "runtime".

[jpnurmi]

Hi @GtechGovind, I'm fixing up the basics for Wine and setting up a CI test pipeline at #2001. Once we have it merged, we can update this PR to test the Wine context in an actual Wine environment. I'd prefer it over the current unit test that not only forces us to expose internal details in the module API, but also doesn't guarantee that it actually works on Wine. :)

[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.}

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

[jpnurmi]

#2001 has been merged. There's now a dedicated Wine CI job. Let's replace the unit test with an integration test that runs in an actual Wine environment. Here's a starting point:

diff --git a/tests/test_integration_stdout.py b/tests/test_integration_stdout.py
index 54485adc..83cc0da8 100644
--- a/tests/test_integration_stdout.py
+++ b/tests/test_integration_stdout.py
@@ -389,3 +389,32 @@ def test_breakpad_stack_overflow_stdout(cmake, stack_size):
     assert_attachment(envelope)
     assert_minidump(envelope)
     assert_breakpad_crash(envelope)
+
+
+@pytest.mark.skipif(not is_wine, reason="test needs Wine")
+def test_wine_context(cmake):
+    tmp_path = cmake(
+        ["sentry_example"],
+        {
+            "SENTRY_BACKEND": "none",
+            "SENTRY_TRANSPORT": "none",
+        },
+    )
+    env = dict(os.environ)
+    env.pop("STEAM_COMPAT_DATA_PATH", None)
+
+    output = check_output(
+        tmp_path,
+        "sentry_example",
+        ["stdout", "capture-event"],
+        env=env,
+    )
+    context = Envelope.deserialize(output).get_event()["contexts"]["wine"]
+
+    version = subprocess.check_output(["wine", "--version"], text=True).split()[0]
+    assert version.startswith("wine-")
+    assert context == {
+        "type": "runtime",
+        "name": "Wine",
+        "version": version.removeprefix("wine-"),
+    }

[jpnurmi]

we can remove all unit-testing-related changes from the header

[jpnurmi]

Suggested change

	if (!compat_path || !compat_path[0]) {
	if (sentry__string_empty(compat_path)) {