feat: TCP connect fallback for ping, flag high latency vs. ping

- If a peer filters ICMP, measure the TCP connect time to its peer port
  instead; such values are marked with a trailing "t"
- Show ⚡ between Latency and Ping when stellar-core's latency exceeds
  the ping/TCP RTT by more than LATENCY_PING_RATIO (3), hinting at a
  VPN exit / relay in front of the actual node
- Legend below the peer table, only for markers actually shown

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

CLAUDE.md

@@ -49,7 +49,7 @@ Single self-contained script (`pi-stat`). Logic is split into helper functions a
 - **PostgreSQL** — `psql` inside the container; used for peer DB counts and pubkey→IP mapping
 - **ZFS CLI** — `zpool`/`zfs` commands on the host for disk health (`z01pool`); if `zpool` is not found (`HAS_ZFS = False`), falls back to `shutil.disk_usage()` — works on Linux without ZFS, WSL2, and Windows
 - **ip-api.com** — batch geolocation (Country, City), cached in `_geo_cache`; only fetched with `-g`
-- **System `ping`** — one ICMP ping per peer IP from the host (`ping_batch()`, parallel, 1 s timeout, private IPs skipped); shown as `Ping` next to stellar-core's `Latency` in the `-p`/`-g` table, `—` if the peer filters ICMP
+- **System `ping` / TCP connect** — per peer from the host (`ping_batch()`, parallel, private IPs skipped): one ICMP ping (1 s timeout); if the peer filters ICMP, falls back to a TCP connect on the peer port from its address (1 s timeout). Shown as `Ping` next to stellar-core's `Latency` in the `-p`/`-g` table; TCP values are marked with a trailing `t` (legend printed below the table), `—` if neither answers
 
 ### Output sections (in order)
 
@@ -76,7 +76,7 @@ The refresh deadline is anchored to the start of the cycle (`cycle_start`), not
 - **Dynamic column widths** — all table columns sized at runtime from actual data length
 - **NAT detection** — inbound peers with private IPs are replaced with their DB-stored public IP (`db_peer_addr` from PostgreSQL)
 - **Validator matching** — `load_validators()` parses `stellar-core.cfg` and indexes by IP, name, and public key; matched peers show a truncated key + `(Vn)` label
-- **Ping vs. Latency** — `Latency` is stellar-core's round trip to the peer *process*, `Ping` is ICMP to the peer's IP; a low ping with high latency hints at a VPN exit / relay in front of the actual node
+- **Ping vs. Latency** — `Latency` is stellar-core's round trip to the peer *process*, `Ping` is ICMP to the peer's IP; a low ping with high latency hints at a VPN exit / relay in front of the actual node. Peers with `Latency > LATENCY_PING_RATIO (3) × Ping` get a `⚡` between the two columns (2-column cell, since `⚡` is double-width in terminals); a legend line is printed below the table only when a `⚡` or `t` marker is present
 - **Geo caching** — `_geo_cache` is a module-level dict; `geo_batch()` only fetches IPs not already cached
 - **Flag parsing** — manual `sys.argv` parsing; `-g` implies `-p`; `-i` accepts an optional next argument as the refresh interval
 - **Config precedence** — `config_refresh()` reads the config value; an explicit `-i SEC` argument overrides it