Cluster-wide config switch over RPC: treat client timeout as 'unknown', then verify every node

Seen while testing a 10-node course KV store: a coordinator broadcast a mode-switch RPC with a 3s per-node timeout and labeled timeouts as 'unreachable'. On one run three nodes were reported unreachable even though their logs showed the switch applied ~3.7s later (switch involved truncating + fsyncing a WAL, plus an occasionally slow first connection); repeat runs took 0.3-1.8s. Lessons: (1) a client-side timeout means 'outcome unknown', not 'not applied', so report it as 'no reply in time (may have applied)' and keep the timeout generous for anything doing fsyncs; (2) make the switch idempotent and have automation verify by reading back each node's state (e.g. a mode command on every node) and retrying until all agree, before starting multi-minute benchmark runs, so a silently unswitched node can't poison results.