币池可配，实测十币的排队代价；标出漂移的 tick 地板

加 --syms（start.sh 传 SYMS），默认仍是三币。TRX 不进十币池：实盘口径 208 天
只有 5 笔，ATR 门控几乎全刷掉。

十币实测（对比三币）：

  queue_ms        2 → 169ms（P90 519ms，每刻最大排队中位 533ms）
  inner_ms      144 → 196ms（CPU 争抢也拖慢了纯计算）
  lag_signal_ms 621 → 958ms；同一收盘时刻最后算完的币中位 1376ms

排队从可忽略变成主项，与「10 币 × 196ms ÷ 2 核 ≈ 640ms 突发」吻合。这也是
之前「加核没用」那个结论唯一会翻转的场景：CPU 占用率只有约 3%，问题纯粹是
所有币同一秒收盘的突发，加核压的是并行度而非单币耗时。

但 800ms 哨兵不受影响——它喂的是 t_data − kline_ts（数据腿），十币下逐币
154~532ms 全在线内。加币不碰那道闸。

另外发现一个会被静默误读的东西：ADA/AVAX/DOGE/LINK/LTC 的漂移中位精确等于
半个 tick 且在四个延迟点上完全相同。那不是漂移，是中价的最小变动量——ADA 半
tick 就有 2.34bp。拿这个数去比预算会误判某币不可做。shadow_report 加了
tick_floor() 标注；方向上安全（真实漂移只会更小，这些是上界）。

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

research/live/deploy/start.sh

@@ -17,6 +17,10 @@ NAME="${NAME:-shadow}"
 # verify_lean_parity.py 在影子这条路径上逐根验过（180 窗口 / 90 命中零分歧）。
 # 设 0 可退回 full，用来复量两模式的耗时差。
 SHADOW_LEAN="${SHADOW_LEAN:-1}"
+# 币池。默认三个流动性最好的做滑点测量；十币池是实际要交易的那批（TRX 剔除，
+# ATR 门控几乎全刷掉）。币数直接决定排队：所有币同一秒收盘，2 核上 10 个币
+# 需要约 640ms 墙钟才算完，最后一个币的信号会落在 800ms 哨兵线之外。
+SYMS="${SYMS:-BTC,ETH,SOL}"
 IMAGE="${SHADOW_IMAGE:-hummingbot/hummingbot:latest}"
 HOURS="${HOURS:-168}"
 WORKERS="${WORKERS:-2}"
@@ -108,7 +112,7 @@ docker run -d --name "$NAME" -w /home/hummingbot \
 	-v "$OUT:/out" \
 	--entrypoint /opt/conda/envs/hummingbot/bin/python \
 	"$IMAGE" /repo/research/live/shadow_hb.py \
-	--hours "$HOURS" --workers "$WORKERS" >/dev/null
+	--hours "$HOURS" --workers "$WORKERS" --syms "$SYMS" >/dev/null
 
 echo "已启动。等启动自检（补丁断言 + 历史回填，约 60 秒）…"
 sleep 45