Verify replication peer identity against the configured hostname

## Problem

When a CA is configured, replication TLS validates the certificate chain. The client does not
configure SNI or verify that the certificate hostname or IP matches the `REPLICAOF` target.

Consequently, any certificate signed by the trusted CA may authenticate as the configured master,
even when its subject alternative names do not match that master. This matters when replication or
slot migration crosses an untrusted network.

Without a CA, the code explicitly uses `SSL_VERIFY_NONE`; this mode should be documented as
encryption without server authentication.

## References

https://github.com/dragonflydb/dragonfly/blob/980c70331d194d7133079917668fec269444c65c/src/server/protocol_client.cc#L109-L123

https://github.com/dragonflydb/dragonfly/blob/980c70331d194d7133079917668fec269444c65c/src/server/protocol_client.cc#L179-L205

https://github.com/dragonflydb/dragonfly/blob/980c70331d194d7133079917668fec269444c65c/src/facade/tls_helpers.cc#L81-L138

https://github.com/dragonflydb/dragonfly/blob/980c70331d194d7133079917668fec269444c65c/src/server/cluster/outgoing_slot_migration.cc#L117-L124

Start with the referenced replication TLS paths in src/server/protocol_client.cc and src/facade/tls_helpers.cc, then inspect the slot-migration caller in src/server/cluster/outgoing_slot_migration.cc. Trace how the REPLICAOF target and CA configuration reach the TLS connection. Done means a CA-backed connection checks the configured hostname or IP, while the SSL_VERIFY_NONE behavior without a CA is documented as encryption without server authentication.

Written by the indexing model from the issue text.