Reproduce the CAIN-42 etcd coordination-cluster evidence (no CAIN code).

1. Read the capture.

   ETCD_CLUSTER.json holds the cluster id, the three members (etcd member id,
   name, region, peer URL, client URL), the raft leader, and the raw output of
   the four commands that produced them.

2. Re-check it live (Python 3.8+, standard library only).

       python3 verify_etcd_cluster.py ETCD_CLUSTER.json

   It asks the leader's public etcd API (/v3/maintenance/status,
   /v3/cluster/member/list, /version, /health) and prints VERDICT: PASS when the
   cluster id, the raft leader, the member set and the etcd version still match
   the capture.

3. Or by hand.

       curl -sS -X POST http://45.76.60.231:2379/v3/maintenance/status  -d '{}'
       curl -sS -X POST http://45.76.60.231:2379/v3/cluster/member/list -d '{}'
       curl -sS http://45.76.60.231:2379/version
       curl -sS http://45.76.60.231:2379/health

   /version also answers on the peer port 2380 of all three members:
   http://45.76.60.231:2380/version, http://45.76.169.191:2380/version,
   http://207.246.66.130:2380/version.

What this proves: an etcd 3.5.9 cluster with cluster id 10933886556755453700
exists, who its members are, and which member holds the raft leadership, at the
moment you run it.

What it does not prove: that the membership or the leader is stable (a raft
re-election moves the leader), that the etcd API is authenticated to you, or that
etcd authorizes any CAIN action. etcd coordinates; CAIN's PBFT clusters
authorize. This is one more piece of live infrastructure, not a safety or
authorization claim.