fix(mcp): select a rustls crypto provider

[hippiuS]

Summary

• select the aws-lc-rs rustls CryptoProvider before the MCP server creates TLS clients
• preserve a provider already installed by an embedding host and tolerate the install race
• add a bounded subprocess regression test that initializes MCP, verifies redis_type is registered, and exercises a real rediss:// tool call

Why

The default redisctl-mcp feature graph enables two rustls providers: reqwest 0.13 brings aws-lc-rs, while the Redis client brings ring. Rustls 0.23 cannot choose between them automatically, so the first Redis TLS data-plane call panics with:

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

The server initializes and lists tools successfully before that point, which makes the failure appear command-specific even though any Redis command over TLS can trigger it.

Compatibility

This is a safety correction. It does not add, remove, or rename MCP tools, change their schemas, or alter CLI output/contracts. The catalog baseline is unchanged.

Tests

• RED without the startup selection: the test initializes MCP and lists redis_type, then the TLS tool call reproduces the CryptoProvider panic
• GREEN with the fix: the same call returns a normal MCP isError: true connection failure and the process exits cleanly
• the subprocess has a 10-second cross-platform timeout, drains stdout/stderr concurrently, and is killed/reaped on timeout
• cargo fmt --all -- --check
• cargo clippy -p redisctl-mcp --all-targets --all-features -- -D warnings
• cargo test -p redisctl-mcp --test tls_crypto_provider --all-features -- --nocapture
• cargo test -p redisctl-mcp --all-features catalog_contract::mcp_catalog_matches_1_0_baseline

The repository workflows were created with action_required because this is a first-time fork contribution. A maintainer needs to approve them before the full workspace CI gate can run.