Cucumber crashes on Windows 11 with JRuby 10 when loading `sys-uname` through `jruby-win32ole`

### 👓 What did you see?

We would like to use Cucumber on Windows 11 with JRuby 10.0 or later.
The Cucumber documentation currently lists JRuby 10.0+ as a supported platform, subject to some limitations.

Our project uses the following `Gemfile`:

```ruby
source 'https://rubygems.org'

gem 'jruby-win32ole', '>= 0.8.5'
gem 'cucumber', '>= 11.1.1'
```

`jruby-win32ole` is required in our JRuby-based Windows environment.

When we start the Cucumber runner, the JVM crashes with the following native error:

```text
# JRE version: OpenJDK Runtime Environment OpenLogic-OpenJDK
# (21.0.9+10)
#
# Java VM: OpenJDK 64-Bit Server VM OpenLogic-OpenJDK
# (21.0.9+10, mixed mode, sharing, tiered, compressed oops,
# compressed class ptrs, g1 gc, windows-amd64)
#
# Problematic frame:
# C [racob-x64.dll+0x1aa4]
#
# No core dump will be written.
# Minidumps are not enabled by default on client versions of Windows.
#
# An error report file with more information is saved as:
# C:\Users\xxx\Documents\ADOWorkspace\JRubyWorkspace\
# try-jruby-cucumber\hs_err_pid7724.log
```

## Investigation

I investigated why `jruby-win32ole` is loaded when starting Cucumber.

The dependency is introduced through the `sys-uname` gem. In the current Cucumber code, the operating-system version exposed by `sys-uname` is used by `Cucumber::Runtime::MetaMessageBuilder#os`:

```ruby
def os
Cucumber::Messages::Product.new(
name: RbConfig::CONFIG['target_os'],
version: Sys::Uname.version
)
end
```

As far as I can determine, this operating-system metadata is the only Cucumber functionality that requires `Sys::Uname`.

In addition, `lib/cucumber/runtime.rb` requires `sys/uname`, although that file does not use `Sys::Uname` directly. Requiring it there causes the native Windows integration to be loaded during Cucumber startup.

On JRuby running on Windows, this ultimately loads `racob-x64.dll`, after which the JVM terminates with a native crash. Because this is a native JVM crash, it cannot be handled by rescuing a Ruby exception.

## Proposed approach

Would you consider making the `sys-uname` integration optional on JRuby for Windows?

The unconditional require could be removed from:

```text
lib/cucumber/runtime.rb
```

The dependency could then be loaded only where the operating-system metadata is built:

```ruby
begin
require 'sys/uname' unless RUBY_ENGINE == 'jruby' && Gem.win_platform?
rescue LoadError
# sys-uname is optional. OS-version metadata will fall back
# to a platform-independent value when it is unavailable.
end
```

The operating-system version could use a fallback when `Sys::Uname` is unavailable:

```ruby
def os
Cucumber::Messages::Product.new(
name: RbConfig::CONFIG['target_os'],
version: os_version
)
end

def os_version
return Sys::Uname.version if defined?(Sys::Uname)

'unknown'
end
```

This preserves the existing `sys-uname` behavior on supported runtime and platform combinations, while avoiding the native `jruby-win32ole` code path on JRuby for Windows.

### ✅ What did you expect to see?

Cucumber should start successfully on Windows 11 with:

- JRuby 10.0 or later
- Java 21
- Cucumber 11.1.1 or later

If `sys-uname` cannot safely be loaded, Cucumber should still run and report a fallback operating-system version in its metadata.

## Actual behavior

The JVM terminates while loading `racob-x64.dll`, before any Cucumber scenarios are executed.

### 📦 Which tool/library version are you using?

- jruby version = jruby 10.0.6.0 (3.4.5) 2026-06-11 716ad51f54 OpenJDK 64-Bit Server VM 21.0.9+10-adhoc.Administrator.jdk21u on 21.0.9+10-adhoc.Administrator.jdk21u +indy +jit [x86_64-mswin32]
- cucumber 11.1.1

### 🔬 How could we reproduce it?

_No response_

### 📚 Any additional context?

[hs_err_pid7724.log](https://github.com/user-attachments/files/31739851/hs_err_pid7724.log)

Read lib/cucumber/runtime.rb and the Cucumber::Runtime::MetaMessageBuilder#os entry point, then trace when sys/uname is loaded during startup. Check Cucumber startup on JRuby 10+ under Windows and confirm that it avoids the native crash while still producing OS metadata, with a fallback version when sys-uname is unavailable and existing behavior preserved elsewhere.

Written by the indexing model from the issue text.