影子路径开 lean 模式，实测完整链路 1410 → 683ms

拉到新引擎后在服务器侧直接实测，没有沿用 3.4 倍那个换算——那是在旧代码上量的。

先做等价性验证。不能直接引用 step46 的对拍结论：它固化的是 bsp_list 那条链的
哈希，而影子路径走 find_fast_bsp3 + build_htf_zones + htf_fx_timeline +
attach_htf_context，两条链读的东西不一样。所以新建 verify_lean_parity.py 在
这条路径上逐根对拍 compute() 的每个返回字段。

其中一个坑：随机取窗口测不到信号分支。信号密度约 1/2000 根，头 12 个窗口命中
0 个，「一致」只覆盖了早退路径。改成一半窗口对齐到已知信号根，命中率才上来。
最终 180 窗口 / 两模式各 90 命中 / 零分歧。

生产实测（inner_ms，容器内同口径）：

  compute_ms      646 → 132ms   4.89x
  inner_ms        612 → 128ms   4.80x
  lag_signal_ms  1410 → 683ms   完整链路，落回 800ms 线内

比 3.4 倍更好，因为是引擎 ~3.5x 叠 lean ~1.35x。

两点判读上的订正：

- lag_data_ms 那 576→490ms 是噪声，不要记在引擎账上。均值 721±36 vs
  740±127，重叠；而且引擎本来就影响不到交易所与网络那一段。
- 仍有 44% 的根超 800ms，但尾部现在完全由数据腿主导（lag_data P90 1482ms
  vs compute P90 237ms）。计算既不是瓶颈也不是尾部主因了，继续压计算换不到
  尾部改善。800ms 那道闸取的是最近 30 根的中位数，683ms 已满足。

start.sh 加 SHADOW_LEAN（默认 1），设 0 可退回 full 复量两模式差异。

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

research/live/deploy/start.sh

@@ -13,6 +13,10 @@
 set -euo pipefail
 
 NAME="${NAME:-shadow}"
+# lean 模式让 TF_DF 只构建到中枢，跳过线段/走势中枢/MACD 状态机。等价性由
+# verify_lean_parity.py 在影子这条路径上逐根验过（180 窗口 / 90 命中零分歧）。
+# 设 0 可退回 full，用来复量两模式的耗时差。
+SHADOW_LEAN="${SHADOW_LEAN:-1}"
 IMAGE="${SHADOW_IMAGE:-hummingbot/hummingbot:latest}"
 HOURS="${HOURS:-168}"
 WORKERS="${WORKERS:-2}"
@@ -99,6 +103,7 @@ docker run -d --name "$NAME" -w /home/hummingbot \
 	--restart unless-stopped \
 	-e PYTHONPATH=/home/hummingbot:/repo/research:/repo/research/live:/repo \
 	-e SHADOW_SITE="$SHADOW_SITE" \
+	-e SHADOW_LEAN="$SHADOW_LEAN" \
 	-v "$REPO_ROOT:/repo:ro" \
 	-v "$OUT:/out" \
 	--entrypoint /opt/conda/envs/hummingbot/bin/python \