定位 inner_ms 的 3.3 倍：是争抢不是算法档，撤回 22/86 拆分

服务端跑 probe_inner.py 与本机对表：分档占比一致（TF_DF 两腿 68~74%，
信号链 16~21ms），此前报的「chan 构建 22ms / 信号链 86ms」是无效减法
——孤立环境的 1m append 减在场十币的 inner_ms，还漏了 5m 腿。

真实构成：inner_ms 100ms = 约 30ms 计算 × 3.3 倍争抢。逐个排除
_rebuild(1.6ms)、币种差异、周期重建(21.5%/1.5x)、批内次序(相关-0.083)
后，用外生的到达密集度确认（67→117ms），并以注入合成负载复现
（2 个满载进程 2.68x，3 个 2.86x，在场实测 2.24~3.34x）。

心跳判定不再推荐「继续压算法」，改为加核或减币。

第一版用 t_signal-inner_ms 反推并发区间得相关 0.533，是循环构造，
已废弃并在 §5.72 记下这个坑。

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

research/live/shadow_hb.py

@@ -856,7 +856,9 @@ class Shadow:
            144ms 抬到 192ms，反而超过 queue 135ms，于是判定落到「量级已低、
            无需优化」，而此时最后一个币已经落在 1376ms。
 
-        所以币数超过核数时，唯一的出路是压单币耗时（增量计算），不是加 worker。
+        所以币数超过核数时，加 worker 不增吞吐。出路有两级：先上增量把真实计算
+        压下来；增量之后剩的是争抢放大（实测 3.3 倍，§5.72），那一级只能加核或
+        减币，继续改算法收益有限。
         """
         if not np.isfinite(clear):
             return "样本不足，暂不判定"
@@ -872,10 +874,13 @@ class Shadow:
         if not INCR_ON:
             return (f"币数 {len(SYMS)} > 核数 {CORES}，加 worker 无用（CPU 密集）"
                     f"。压单币耗时 → 开 SHADOW_INCR=1 走增量（实测 3.56x）")
-        return (f"币数 {len(SYMS)} > 核数 {CORES}，且增量已生效。单币 {i:.0f}ms "
-                f"里 chan 构建仅约 22ms，其余是 build_htf_zones / "
-                f"find_fast_bsp3 / attach_htf_context —— 要继续压得改这三个，"
-                f"或减币")
+        # 增量已生效时，单币耗时的大头不再是算法而是争抢：离线同一窗口 30ms，
+        # 在场 100ms，注入合成负载能复现这个倍数（HANDOFF §5.72）。所以这里不能
+        # 再推荐「继续改算法」——那是按 3.3 倍虚高的数去优化 30ms 的真实计算
+        return (f"币数 {len(SYMS)} > 核数 {CORES}，增量已生效，加 worker 无用"
+                f"（worker 已等于核数）。单币 {i:.0f}ms 里真实计算约 30ms，"
+                f"其余是 {CORES} 核上争抢的放大 —— 杠杆是加核或减币，"
+                f"不是继续压算法")
 
     async def run(self) -> None:
         await self.start()