CLUSTERX SETNODES returns "Invalid cluster node port" when the bus port (default = client + 10000) is not reachable

## Summary

In container/Mesos/Kubernetes-style environments only a single TCP port
is exposed per data node; the implicit "cluster bus port = client + 10000"
that Redis Cluster uses is not reserved by the scheduler and is not
listening. `CLUSTERX SETNODES` then refuses any well-formed nodes string:

```
> CLUSTERX SETNODES " :@ master - 0-5460" 100
-ERR Invalid cluster node port
```

Stripping `@` (i.e. passing only `:`) fails the same way.

This blocks operators from using `SETNODES` as a manual recovery path
when the controller-managed propagation falls behind (see related
`apache/kvrocks-controller` issue).

## Expected

When `cluster-announce-bus-port` is 0 (or absent from the nodes string),
skip the bus-port reachability validation, or fall back to the client port.
The bus port should not be a strict requirement when nodes are managed
by an external controller that drives them solely over the client port.

## Versions

- Apache Kvrocks 2.15.0

## Environment context

- Aurora/Mesos dynamic-port scheduler — each task is given **one** port
(the `kvrocks` port). Adding `+10000` for the bus port lands on a port
the kernel has not bound and that the firewall has not allowed.
- Same shape applies to Kubernetes Services that expose only one port,
or Docker containers run with `-p :` only.

Start by locating the C++ implementation and tests for the CLUSTERX SETNODES command and its cluster-announce-bus-port validation. Reproduce the command with a client port and unreachable bus port, then verify that a zero or absent bus port no longer causes the invalid-port error while valid bus-port checks remain intact.

Written by the indexing model from the issue text.