feat(ruby): platform-native gem packaging + release-gem workflow

[suchintan]

https://github.com/Skyvern-AI/rustwright-cloud/pull/98

[claude]

Summary

Straightforward Ruby packaging change (synced from rustwright-cloud#98): adds platform-native gem support (native lib bundled per-platform, resolution fallback chain, and a package.rb build script). Logic is small and reads correctly; main gaps are test coverage and a title/diff mismatch.

🔴 Critical Issues (0)

None found.

🟡 Suggestions (2)

• Title says "release-gem workflow" but no workflow file is in this diff. The PR title is feat(ruby): platform-native gem packaging + release-gem workflow, but only ruby/.gitignore, ruby/README.md, ruby/lib/rustwright.rb, ruby/package.rb, and ruby/rustwright.gemspec changed — no .github/workflows/*.yml for gem release. If the workflow lives in a separate PR/repo, worth noting in the description so reviewers aren't left assuming CI automation shipped with this change.
• No test coverage for the new platform-detection/resolution logic. bundled_platform, bundled_library_path, and the new fallback order in default_library_path (ruby/lib/rustwright.rb:99-153) have no corresponding cases in ruby/test/contract_test.rb. These are pure functions of RbConfig::CONFIG['host_os']/host_cpu and are easy to unit test by stubbing RbConfig::CONFIG — worth adding a few cases (each of the 4 supported platforms + an unsupported one falling through to source_library_path) to lock in the resolution order the README now documents.

📝 Minor / Style (2)

• ruby/package.rb: the script trusts that the native library passed via ARGV[1] matches the extension expected for ARGV[0] (e.g. someone could pass a .so file while building the arm64-darwin gem, which expects .dylib). Not exploitable, but a quick extension check against PLATFORMS.fetch(platform) would catch an obvious operator mistake before it ships a broken gem.
• ruby/lib/rustwright.rb:111: bundled_library_path is public while its helper bundled_platform is private — intentional if it's meant to be a public inspection point, but if it's only used internally by default_library_path, consider moving it under private for a smaller public surface.