主口径仓位定为 10 万 USDT，并量出限价单前方的排队量

用户 2026-08-28 确认资金规模不会更大，故仓位档改为 25k/50k/100k/200k
（上下留档是为了读出局部斜率，单点看不出再大一倍会怎样）。该规模下两条
约束都不绑定：冲击占预算 0.1~11.1%，成交量效应使预算降幅不足 1%。

新增 queue_ahead：排队是唯一还没建模的成本项，exit_fill 假定我们能吃到该
价位的全部对手方成交量。10 万仓位相对最优档为 BTC 0.2 倍、ETH 0.7 倍、
SOL 69.7 倍。SOL 畸高是 tick 更细所致（同样的量摊到约 10 倍价位上），
对它应看 5bp 档（0.17 倍），但仍是三币中排队压力最大者。

同时在 shadow_depth 模块头标注：composite_fill 只算首次触及那一根的可成交
量，系统性偏悲观，不作为成交率结论——真实成交率见 lib/exit_fill.py。

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

research/live/shadow_hb.py

@@ -77,10 +77,11 @@ BOOK_KEEP_S = 30                        # 缓冲保留 30 秒,够回查到 +5s
 BOOK_TOL_MS = 250                       # 回查容差:10Hz 正常 ≤100ms,留些余量
 BOOK_DEPTH = 50                         # 双边各 50 档，实测能撑 78 万~261 万美元
 DELAYS_S = (0.5, 1.0, 2.0, 5.0)         # 回查点
-# 便利视图用的仓位档。**真正的答案在 shadow_books.jsonl.gz 里**——完整盘口
-# 落了盘，任意资金量级的冲击都能离线算，换个规模不必重测。这里的档位只是
-# 为了让 CSV 直接可读，覆盖到按 2ATR 止损反推的十万量级真实仓位
-NOTIONALS = (50_000.0, 100_000.0, 320_000.0, 530_000.0)
+# 主口径 10 万名义额（2026-08-28 定：不会有更大资金）。上下各留两档是为了
+# 读出局部斜率——单点看不出「再大一倍会怎样」。
+# **真正的答案在 shadow_books.jsonl.gz 里**：完整盘口已落盘，任意资金量级的
+# 冲击都能离线重算，换规模不必重测，这里的档位只为让 CSV 直接可读
+NOTIONALS = (25_000.0, 50_000.0, 100_000.0, 200_000.0)
 NUM_COLS = ["timestamp", "open", "high", "low", "close", "volume"]