JianFeeeee
49ec22f916
fix(pi): 等人点头的 worker 不再占并发额度，也不会被硬超时杀掉
实测（今天全 Agent 演练时撞到的）：pi 的 `maxWorkers=3` 被**三个正在等人工授权**的
worker 吃满，于是新邮件只能排队 —— 而人可能十分钟后才看邮箱。清掉卡住的请求后队列
立即排空，机制本身没错，错的是"等待"被当成了"在干活"。
两处改动（`src/pool.mjs`）：
1. **等待期间让出并发额度**。worker 发 `permission_pending` 时把它的 entry 标为
parked，`pump()` 只数"在干活"的（`activeCount()`）。停放另有上限 `maxParked`
（默认 5，防止内存无界：每 worker 约 140MB）；超出后仍占额度并打日志说明。
决策到达（`routePermission`）时解除停放，回到额度里。
2. **等待期间暂停硬超时**。硬超时的用途是回收**卡死**的进程，而等人点头不是卡死：
停放时清掉计时器，决策到达后重新起一个完整窗口。否则 worker 会在人还在读邮件时
被 SIGKILL —— 那次工具调用直接消失，人后来批了也没人接（这类"批了没反应"的现象
与此吻合）。
判据（`test/pool.test.mjs` 新增 3 条）：
· ★ 等待授权的 worker 让出额度：另一个会话的邮件必须能开跑
· ★ 等人点头期间（800ms > 300ms 硬超时）不得被强杀，且恢复后能跑完
· 停放有上限：超出后仍占额度（不无限超发）
**扰动验证**：整块回退到 HEAD → 3 条全红；修复后 3/3。全量 pi 套件 420/420。
已部署（快照 20260913-131216，桥重启并重新心跳）。
2026-09-13 13:14:56 +08:00
..
2026-09-03 12:09:12 +08:00
2026-09-04 11:14:44 +08:00
2026-09-12 11:20:13 +08:00
2026-09-06 15:18:06 +08:00
2026-09-03 12:09:12 +08:00
2026-09-03 12:09:12 +08:00
2026-09-13 10:39:26 +08:00
2026-09-03 12:09:12 +08:00
2026-09-03 12:09:12 +08:00
2026-09-12 23:13:48 +08:00
2026-09-03 21:10:48 +08:00
2026-09-11 23:59:24 +08:00
2026-09-13 13:14:56 +08:00
2026-09-12 23:13:48 +08:00
2026-09-04 23:52:52 +08:00
2026-09-08 19:16:35 +08:00
2026-09-06 15:18:30 +08:00
2026-09-03 12:09:12 +08:00
2026-09-11 12:03:51 +08:00
2026-09-03 21:11:15 +08:00
2026-09-12 23:31:44 +08:00
2026-09-11 10:44:18 +08:00
2026-09-03 12:09:12 +08:00