exp+fix: commit2 增益重扫（gain2.2 到达 50.8%，n=512）+ 浏览器安全层三点修复（限位夹紧/部分前缀/离散认证）

- gain 1.8/2.2/2.5/2.8 = 50.4/52.0/49.6/47.7%（n=256），2.2 最佳；n=512 复核 50.8%/1.4% 碰撞
- 积分反馈与反馈隔次复用均为负结论（−4.0/−5.1 pp）
- JS：tick/候选投影夹 LIM（原越限后 inBox 永久拒绝→刹停）；safety_partial 移植；segCert 开关（默认严格）
- bench nc10 --seg 0：刹车率 79.5→48.1%、planP50 56.1→33.5ms、ok 0→5/10

docs/探索日志.md

@@ -447,6 +447,36 @@
   - **新历史最佳（50 Hz 目标节奏，commit=2）= 49.2% / 碰撞 2.3% / ratio2s 0.351 / time_ok 26.2%**；非实时上限（commit=1）= 57.4%（n=256，待 n=512 复核）。
 - **下一步**：① n=512 复核 commit=1；② 积分反馈（fb_ki，针对慢变偏差）在 commit=2 上叠加；③ 浏览器 JS 端同步解析 J；④ commit=2 的 40 ms 周期实测规划 P99（Python/JS）。
 
+## 轮次 27：解析 J 后重扫增益 + 积分/缓存反馈（负结论）+ 浏览器安全层对齐（exp: `exp/dagger-deploy`）
+
+- **目标**：解析雅可比改变了反馈噪声结构，重扫增益；同时修浏览器部署路径的安全层（轮次 25 遗留：bench 刹车 47%、到达 0）。
+- **增益重扫（commit=2，empty，analytic，n=256）**：
+
+| gain | 到达 | time_ok_1p3 | 碰撞 | ratio2s | 刹停/题 |
+|---|---|---|---|---|---|
+| 1.8 | 50.4% | 27.0% | 2.0% | 0.287 | 22.1 |
+| **2.2** | **52.0%** | 29.7% | 1.6% | 0.329 | 35.3 |
+| 2.5 | 49.6% | 34.4% | 1.2% | 0.334 | 47.9 |
+| 2.8 | 47.7% | **34.4%** | 2.0% | 0.362 | 59.8 |
+
+- **n=512 复核 gain 2.2（commit=2）**：**到达 50.8% / time_ok 28.9% / 碰撞 1.4% / ratio2s 0.343 / 刹停 35.9**。**新历史最佳（50 Hz 节奏）= gain 2.2 + commit=2**。
+- **负结论**：
+  - 积分反馈（fb_ki=0.3，decay0.9，限幅0.5·STEP）：到达 48.0%（gain2.2 单独 52.0%），−4.0 pp。慢变偏差用积分项补偿会过冲，不采用。
+  - 反馈隔次复用（fb_every=2，省 ~3.5 ms/次规划）：到达 46.9%（−5.1 pp）。误差方向变化比预期快，缓存不成立。
+- **浏览器部署修复（有效）**：三个与 Python 仿真不一致的 bug 修掉后（`webapp/js/ik-policy.js`）：
+  1. `tick` 不夹关节限位（Python `clamp_box` 每步夹）→ q 一旦越限，认证的 `inBox` 永远拒绝所有候选，原地刹停到超时（certWhy.box 2650 次）；现执行与候选投影都夹 LIM。
+  2. 安全层整段拒绝 → 刹停；移植 `safety_partial`：整段不过时依次缩短前缀，执行到第一个不安全步。
+  3. 新增 `segCert` 开关（默认 true）：连续区间认证（距离下界递归）~40 ms/次，是 50 Hz 预算的主要超支项；关闭后改为离散判定「每步端点+中点 collideFree」（与 Python 安全层同口径），默认仍走严格认证，bench 用 `--seg 0` 测部署口径。
+  - JS bench（nc10，fb2.2，commit2；`node tests/policy_bench.cjs ... --seg 0`）：
+
+| 集合 | 修复前 ok/reached | 修复后 ok/reached | 刹车率 | safety P50 | plan P50 / P99 |
+|---|---|---|---|---|---|
+| near_column_pos | 0/—（轮次 25） | **5/7** | 79.5→**48.1%** | 41.6→**19.8 ms** | 56.1→**33.5 / 61.1 ms** |
+| near_column_pose | 0/— | **3/3** | 80.4→**31.6%** | 43.4→**22.8 ms** | 57.3→**37.6 / 66.3 ms** |
+
+- **结论**：实时配置定为 `dag2 + 解析 J + gain2.2 + commit2 + safety_partial + replan=empty`：n=512 到达 **50.8%**、碰撞 **1.4%**。浏览器端从「0 到达 + 47% 刹车」恢复到 nc 集可达，plan P50 33.5/37.6 ms；P99 仍 61–66 ms，commit=2 的 40 ms 队列会偶发饥饿，需继续压 P99（K/安全候选数/JS 特征）。
+- **下一步**：① Python 测 `safety_try=1`（只认证首选候选）对准确率的影响，若无损则 JS 同步（省多次 collideFree）；② K=4/6 的准确率-时延权衡；③ JS `gapMatrix` 同步只算 8 组特征；④ commit=2 异步部署的饥饿率实测。
+
 ## 分支清理（2026-10-20）
 
 - `feat/fb-mix`（8e5431c）：反馈混合方案的中间分支，**已验证是 `exp/dagger-deploy` 的祖先**（所有提交都在后者历史里），本地/远端分支删除，内容保留在 exp/dagger-deploy。