release: cut a stable 0.2.0 and unblock the tagged publish workflows

[suchintan]

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

[claude]

Summary

Clean, mechanical release-prep PR: bumps every crate/package to a unified 0.2.0, adds the CHANGELOG entry, and substantially expands docs/RELEASING.md to cover the newly-added NuGet/RubyGems/Maven release channels. No engine (src/lib.rs, CDP layer, Python/Node API surface) code changes — nothing security- or correctness-sensitive here. I cross-checked all version fields (Cargo.toml/Cargo.lock ×3 workspaces, pyproject.toml, node/package.json+lock, csharp/*.csproj, ruby/lib/rustwright.rb, java/build.gradle.kts both sites, java/README.md) and they're fully consistent at 0.2.0; tests/test_changelog.py's structural checks (ordering, dates, required categories) pass against the new CHANGELOG section by inspection.

🔴 Critical Issues (0)

None found.

🟡 Suggestions (1)

• docs/RELEASING.md: the new "Verify the registries" line claims release-npm.yml "publishes without an explicit --tag, so npm applies latest." That's not accurate — the workflow's Select dist-tag from version step does pass an explicit --tag (.github/workflows/release-npm.yml:265-278), computed as latest for a stable version and next for a prerelease. The end state for this release (latest) is right, but the stated reason is wrong and could mislead whoever reads this doc during the next prerelease cut (where the tag would actually be next, not the doc's implied default). Worth rewording to describe the actual dist-tag selection logic.

📝 Minor / Style (1)

• docs/RELEASING.md now states rustwright-core and rustwright (rust-native) "are already published on crates.io." I couldn't independently verify current crates.io state from this review — worth a quick confirmation before relying on that claim during the actual publish step, since the doc previously said the opposite ("no crates.io settings or token are currently required").