延迟瓶颈实测为本机 CPU 而非机房位置，跨站对比主指标改为 compute_ms

用户指出本机选新加坡是因为 Bitget 机房在新加坡。查证下来 ws.bitget.com 解析
到的是 CloudFront（dxotqhr62n6z4.cloudfront.net），落在新加坡 AS16509
（Amazon），即连的是 AWS 的 CDN 边缘而非 Bitget 自有机房。

腾讯云 ap-singapore（AS132203）到该边缘实测：ICMP 往返 2.1ms、TCP 握手
3.3ms、TLS 完成 9.0ms、首字节 87.8ms。首字节减 TLS 那约 79ms 是 CloudFront
回源开销，与我们的位置无关。

延迟构成（33 根样本）：数据到达中位 506ms、信号计算中位 646ms、合计 1315ms。
随机房位置变化的只有那 2ms 往返，占总延迟 0.15%。而 646ms 的信号计算是每根
在 2000 根 1m 加 800 根 5m 上重建缠论结构，本机 2 核、2 个计算进程，三币同时
收盘时第三个还要排队——这才是有改善空间的一项。

因此：
- 新增 deploy/netprobe.sh，把网络那一段单独量出来并入运行元数据。用到达
  延迟去比两个机房等于用公斤秤称克，必须把可变的那段拿出来单独看。
- compare_sites.py 主指标改为 compute_ms，lag_data_ms 降为自检项（两站应当
  接近；若差很多，先怀疑时钟而非网络）。元数据表加 nproc/cpu_model/往返。
- README 改写：第二台机器该测 CPU 规格而非地理位置，WORKERS 按核数减一给，
  币数多于 worker 数时排队时间直接计入 compute_ms。

另修正站点标签：本机是腾讯云而非 Hetzner，sg-hetzner → sg-tencent，标错的
33 行数据已清掉重采。

Co-authored-by: Cursor <cursoragent@cursor.com>

research/live/deploy/start.sh

@@ -64,8 +64,13 @@ docker rm -f "$NAME" >/dev/null 2>&1 || true
 
 mkdir -p "$OUT"
 
+say "量网络距离"
+netprobe="$(bash "$(dirname "${BASH_SOURCE[0]}")/netprobe.sh" 2>/dev/null || echo '{}')"
+echo "$netprobe" | grep -E 'edge_org|self_org|self_city|icmp_min_ms|tcp_connect' || true
+
 # 运行元数据。两地数据对不上时，先看这个文件——镜像摘要、代码版本、时钟偏移
-# 三者任一不同都足以解释差异，不必去猜。
+# 三者任一不同都足以解释差异，不必去猜。网络探测并在这里，因为「换机房能省
+# 多少」这个问题只有它能回答（到达延迟里网络只占约 2ms，用它比等于用公斤秤称克）。
 meta="$OUT/run_meta_${SHADOW_SITE}.json"
 cat >"$meta" <<EOF
 {
@@ -82,7 +87,9 @@ cat >"$meta" <<EOF
   "workers": $WORKERS,
   "kernel": "$(uname -r)",
   "nproc": $(nproc),
-  "mem_gb": $(free -g | awk '/^Mem:/{print $2}')
+  "cpu_model": "$(awk -F': ' '/model name/{print $2; exit}' /proc/cpuinfo 2>/dev/null || echo unknown)",
+  "mem_gb": $(free -g | awk '/^Mem:/{print $2}'),
+  "net": $netprobe
 }
 EOF
 echo "元数据已写 $meta"