加跨地部署脚本与站点对比，数据全表加 site 列

目的是在第二台机器（AWS）上跑一套完全相同的采集，看不同地理位置的数据差异。
滑点里最大的一项是延迟漂移，而延迟含网络传输，所以机房选址是可优化参数。

数据侧两处必需改动：

- 全部输出加 site 列（三张 CSV 加 gzip 里的盘口与成交流）。没有这一列，两台
  机器的数据合起来就分不清来源。为免四处 writerow 漏加一处产生静默空值，
  改在 _SiteWriter 里统一注入。
- start.sh 在时钟未同步或偏移超 10ms 时**拒绝启动**。所有延迟数字都是
  「本地时钟 − 交易所 K 线收盘」，时钟偏 50ms 就全部同向偏 50ms，且不报错，
  只会让跨地对比得出一个干净且完全错误的结论。

deploy/ 下四个文件：setup.sh（docker + chrony + 拉镜像）、start.sh（校验时钟、
写运行元数据、起容器）、status.sh（健康速查）、README。运行元数据记 git commit、
镜像摘要、时钟偏移——两地数据对不上时，这三项任一不同都足以解释差异。

compare_sites.py 做配对对比：只取各站都有的 K 线（不取交集可能在比不同时段，
而延迟对市场活跃度敏感），并报配对差的符号占比而非两个中位数相减。已用注入
120ms 的合成数据验证能精确还原。另有一条自检：同一固定延迟点上两站漂移应当
相同——漂移是市场性质，若也差很多则先查时钟与时段对齐。

status.sh 里按列名取字段下标而非写死数字：加 site 列时字段整体右移过一次，
写死 $8 会静默变成读 lag_signal_ms 而非 lag_data_ms。

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

research/live/deploy/README.md

@@ -0,0 +1,97 @@
+# 影子采集器部署
+
+在第二台机器上跑一套完全相同的采集，用来看不同地理位置的数据差异。
+
+## 为什么要跨地采集
+
+滑点里最大的一项是**延迟漂移**：从 K 线收盘到实际下单之间，价格已经走掉的
+那部分。而延迟 = 交易所出包 + 网络传输 + 本地处理。本机（新加坡）实测到达
+延迟中位 350~650ms，其中网络传输占多少、换个机房能压掉多少，只有实测。
+
+延迟压下来直接等于滑点下降，所以机房选址是个可优化参数，不是固定成本。
+
+## 三个必须一致，一个必须不同
+
+必须一致，否则差异分不清是地理位置还是环境造成的：
+
+- **代码版本**（`git_commit`）——同一个 commit
+- **镜像摘要**（`image_digest`）——同一个 hummingbot 镜像
+- **时钟**——两台都同步到 NTP，偏移都在 10ms 内
+
+必须不同：
+
+- **`SHADOW_SITE`**——写进每一行数据，是合并后区分来源的唯一依据
+
+`start.sh` 会把这四项连同内核、核数、内存一起写进
+`research/out/run_meta_<site>.json`。两地数据对不上时先看这个文件。
+
+## 时钟为什么是硬门槛
+
+所有延迟数字都是「本地时钟 − 交易所 K 线收盘时间戳」。时钟偏 50ms，全部
+延迟就同向偏 50ms，而且**不会有任何报错**——只会让跨地对比得出一个干净、
+自信、且完全错误的结论。所以 `start.sh` 在时钟未同步或偏移超阈值时直接
+拒绝启动，而不是打个警告了事。
+
+## 步骤
+
+在新机器上：
+
+```bash
+git clone ssh://jack@git.jackyu66.com:2222/jack/chan.git
+cd chan && git checkout chan
+
+bash research/live/deploy/setup.sh          # 装 docker + chrony，拉镜像
+SHADOW_SITE=aws-tokyo bash research/live/deploy/start.sh
+```
+
+确认健康：
+
+```bash
+bash research/live/deploy/status.sh
+```
+
+启动日志里应当看到：
+
+```
+[补丁] 覆盖生效：基类取首元素 … 本地取末元素 …
+成交流已挂 ['BTC', 'ETH', 'SOL']
+就绪 3.0s · 1m [2001, 2001, 2001] 根 · 5m [801, 801, 801] 根
+```
+
+第一行尤其重要。上游 Bitget 连接器的换根解析有 bug（只取多根消息的首元素），
+补丁把它修掉拿回约 1.06 秒。补丁若失效是静默的——不崩不报错，只是延迟悄悄
+退回 1.4 秒，所以启动时做了断言。
+
+## 对比
+
+把两站的 `research/out/` 收到一处（同名文件会覆盖，所以分目录放）：
+
+```bash
+mkdir -p collected/sg collected/aws
+rsync -av sg-box:chan/research/out/   collected/sg/
+rsync -av aws-box:chan/research/out/  collected/aws/
+
+python research/live/compare_sites.py \
+  --glob 'collected/*/shadow_latency.csv' \
+  --drift-glob 'collected/*/shadow_drift.csv' \
+  --meta-dir collected/sg --meta-dir collected/aws
+```
+
+对比脚本做两件事值得说明：
+
+- **只取各站都有的 K 线**做配对比较。不取交集就可能在比不同时段，而延迟对
+  市场活跃度敏感。
+- 报**配对差的符号占比**而不只是两个中位数相减。同根配对消掉了市场状态，
+  「A 比 B 慢的根占多少」比「两个中位数差多少」更能说明有无系统性差异。
+
+判读上有一条自检：**同一个固定延迟点上，两站的漂移应当几乎相同**——漂移是
+市场性质，与机器位置无关。若漂移也差很多，先怀疑时钟或时段没对齐，而不是
+急着下结论。
+
+## 资源占用
+
+本机实测：内存约 1.5GB（两个计算进程 + 盘口缓冲），CPU 单核不满。
+盘口与成交流落盘约 15MB/天（gzip）。一周 168 小时的量级在百 MB 内。
+
+`--workers 2` 是因为信号计算走独立进程池、不能阻塞事件循环。核数少的机型
+可以给 1，但要看心跳里的 `compute_ms`：若接近 60 秒就会开始堆积。