Closes #315

Summary

Issue #315 reports that Feishu WebSocket mode on Windows x86_64 starts normally, finishes authentication, and then panics as soon as the long connection tries to perform its TLS handshake. In practice that means the bot never finishes bringing up the Feishu WebSocket connection after the v0.1.31 upgrade.

Root Cause

The regression comes from the recent rustls upgrade in de2a4c8.

After that change, the WebSocket TLS path used by tokio-tungstenite resolves to rustls 0.23, which now requires the process to have a concrete CryptoProvider installed before code reaches the default config builder path. In our dependency graph the provider was not unambiguously selected at runtime, so the released binary could panic with:

Could not automatically determine the process-level CryptoProvider from Rustls crate features.

Feishu was the user-visible failure in the issue report, but the same runtime trap also existed anywhere else we open secure WebSocket connections through the same stack, notably Slack Socket Mode and microclaw gateway call against a wss:// endpoint.

Fix

This PR makes the provider selection explicit instead of relying on rustls feature auto-detection.

It adds a direct rustls dependency with the ring + std features enabled, introduces a small tls::ensure_rustls_crypto_provider() helper, and calls that helper before WebSocket connections in Feishu, Slack, and the gateway client path. The helper is idempotent and treats an already-installed provider as success, so it is safe to reuse from multiple entry points without changing existing runtime behavior beyond preventing the panic.

Validation

I verified the dependency feature resolution now includes the ring provider, added a unit test that exercises repeated provider initialization, and ran the full Rust test suite successfully with cargo test.