Test snap sync of all EL clients on 5x mainnet bloated state

Measure snap sync of the x5 milestone (block 24,546,596, stateRoot 0x3b39175c51aa42069de535696db2b1ac113dbd998bcde737b56261018d5da4c2).

Sync pairs — hold the server constant, vary the syncer

The syncing client does ~all the heavy work (download + trie/snapshot build + healing + DB writes), so the syncer is the variable and the server is held constant (NM), which we already have serving the state.

• NM → NM — NM's sync-cost scaling + snap-synced NM DB size (differs from the bloated DB)
• NM → Geth — Geth's sync-cost scaling; also produces the bootable Geth x5 snapshot
• (opportunistic) Geth → Geth — reuses the NM→Geth target as server; isolates server-side effects only

Metrics (the "Sync" category of #21), per pair

• Snap-sync wall time
• Peak / sustained download bandwidth
• Disk IOPS + throughput during sync
• Peak + steady-state RSS post-sync
• Final on-disk DB size

Setup

Source = NM serving x5 (rig VM1). Targets = fresh NM + fresh Geth on VM2 (cross-network). The synced Geth datadir doubles as the bootable Geth x5 cloud snapshot.

Acceptance

• NM→NM and NM→Geth complete VALID at x5
• Metrics committed to benchmarks/x5/ per pair
• Compared vs x3.5 (flag any metric >25% worse)

Boundary: sync only; execution + RPC-latency for x5 live in #21. Depends on #10.

Start with the setup and sync-pair checklist in this issue, using the x5 source on VM1 and fresh NM and Geth targets on VM2 after dependency #10 is complete. Record sync time, bandwidth, disk activity, RSS, and final DB size in benchmarks/x5/; done means both NM→NM and NM→Geth complete VALID and results are compared with x3.5.