Speed up rectification scoring without changing results.

Cache work that depends only on the candidate minute, drop unread response fields, and reject windows above 241 candidates before any chart is built. Eleven canonical scenario hashes match 77057a819. Sealed and reported-offset replays match the 2026-10-08 records (changed_trial_count 8 and 581) and are stored as scoring_perf_2026_10_13.

Co-Authored-By: Grok (agent loop)

docs/BUG_HISTORY.md

@@ -17720,3 +17720,63 @@
 - 复发自：BUG-1306。
 - 修复版本：分支 `codex/rectification-step0-entry-20261013`，尚未合入 staging。
 
+## BUG-1323 | 校正引导窗口按候选两两比较，窗口一长就平方变慢
+
+- 状态：fixed-pending-verify（尚未合入 staging）
+- 首次发现 / 最近更新：2026-10-13 / 2026-10-14
+- 来源：issue #57。任务书 `docs/tasks/TASK-rect-scoring-perf-20261013.md`。
+- 现象：校正把时间窗拉到大约两小时时，每一轮重算要多花好几秒。人看到的候选和分数并没有因此变多。
+- 触发条件：同一次打分里的候选分钟变多。候选越密，引导窗口这一段越接近按平方增长。
+- 根因：`guided_collect_windows` 对代表候选两两比较时，每一对都重新扫全部候选的大运起点。起点只跟「哪一条运、第几个分界」有关，同一分界算一次就够。
+- 修复：每个候选的起点先算好。某个分界已经比出不同并收过窗口后，后面的候选对跳过这个分界。窗口的排序、去重和截断没有改。
+- 验证：`tests/test_rect_scoring_perf_20261013.py` 用基线函数副本对照四种窗口，输出相同；`_context_time` 次数不超过候选数的 16 倍。同机 121 候选这一段从约 4.8 秒降到约 0.6 秒。11 个场景的规范化输出 sha256 与基线 `77057a819` 全部相同。
+- 防复发：上面的线性计数断言。
+- 相关记录：BUG-749、BUG-1324。
+- 复发自：无。
+- 修复版本：分支 `codex/rect-scoring-perf-20261013`，尚未合入 staging。
+
+## BUG-1324 | 只跟候选有关的三样东西仍在每个事件里重算
+
+- 状态：fixed-pending-verify（尚未合入 staging）
+- 首次发现 / 最近更新：2026-10-13 / 2026-10-14
+- 来源：issue #57。关联 BUG-721。
+- 现象：同一个候选分钟上，功能吉凶、那罗延子运、大运换段邻近被每个事件各算一遍。两小时窗口里这三段合计大约一秒多。
+- 触发条件：一次打分有多个事件、多个候选。
+- 根因：功能吉凶只看上升星座，那罗延子运表只看该候选的大运，换段起点只看该候选的月亮（那罗延再加上升）。旧的 BUG-721 要求缓存在请求级静态上下文的顶层，新代码没有照做，测试又只用三到五个候选，所以没拦住。
+- 修复：这两份结果放在候选静态上下文的顶层，不放进特征，因此不改特征指纹。打分时直接用。换段邻近按候选日期和月亮度数各算一次全范围起点，再按事件年份过滤；过滤和原来在事件窗口里现算等价，因为原来的函数只会收下窗口内的年份，空结果也不依赖窗口。探针路径仍不接收子运表，这一项记在进度里，本单不改。
+- 验证：`tests/test_rect_scoring_perf_20261013.py`。功能吉凶在一次 121 候选打分里调用 121 次。打分循环里不再调用 `get_current_narayana_dasha`。缓存结果与现算在 0 到 120 岁、步长 0.01 年上一致。换段矩阵与基线副本一致，含跨午夜。`feature_hash` 不变。
+- 防复发：上述计数断言，以及记忆化测试把这两个顶层键列入可清空层。
+- 相关记录：BUG-721、BUG-1323、BUG-1325。
+- 复发自：无。
+- 修复版本：分支 `codex/rect-scoring-perf-20261013`，尚未合入 staging。
+
+## BUG-1325 | 打分响应里带着没有读取点的内部矩阵和重复回执
+
+- 状态：fixed-pending-verify（尚未合入 staging）
+- 首次发现 / 最近更新：2026-10-13 / 2026-10-14
+- 来源：issue #57。关联 BUG-728。
+- 现象：两小时窗口的默认响应大约 2 MB。其中事件贡献矩阵和一份与对外回执重复的内部回执没有产品读取点。
+- 触发条件：调用校正打分。诊断接口也重复带了那份内部回执。
+- 根因：矩阵和内部回执直接放进了对外响应。新增字段之前没有先找读取点。
+- 修复：默认响应去掉 `event_contribution_matrix` 和 `candidate_decision_receipt`。研究脚本需要矩阵时显式打开 `include_internal=True`。对外仍用原来的 `decision_receipt`。算法版本和策略版本都不改。
+- 验证：`tests/test_rectification_v5_services.py` 默认断言这两个键不在，打开开关后都在。同机 121 候选默认规范化响应约 0.89 MB。11 个场景在打开内部字段并去掉计时字段后，sha256 与基线全部相同。
+- 防复发：默认响应断言这两个键不存在。新响应字段先找读取点。
+- 相关记录：BUG-728、BUG-1324。
+- 复发自：无。
+- 修复版本：分支 `codex/rect-scoring-perf-20261013`，尚未合入 staging。
+
+## BUG-1345 | 打分接口没有候选数上限，超宽窗口会占着重计算槽
+
+- 状态：fixed-pending-verify（尚未合入 staging）
+- 首次发现 / 最近更新：2026-10-14 / 2026-10-14
+- 来源：issue #57。产品 2026-10-14 决定上限 241，与前端放宽到的最长区间一致。
+- 现象：直接调用打分可以一次排一整天、每分钟一个候选。计算还没开始就把重计算槽占住几分钟。
+- 触发条件：候选分钟数超过 241。产品路径的两小时、步长 1，最多 121 个，不受影响。全天扫描在步长 2、5、10 下仍低于上限。
+- 根因：打分按请求里的窗口枚举候选，没有上限。
+- 修复：超过 241 在排盘前拒绝，HTTP 400，正文里有 `too_many_candidates`。接口文件没有改，所以错误码仍是原来的 `ERR_BAD_REQUEST`。前端把这种 400 当成坏请求，不按「服务忙」重试。研究脚本可以用 `enforce_candidate_cap=False` 跳过，本单的冻结重跑没有用到这个开关。
+- 验证：`tests/test_rect_scoring_perf_20261013.py` 覆盖 240、241 通过，242 和全天步长 1 在 50 毫秒内拒绝，步长 2、5、10 通过。前端 `rectification-v9-engine-contract.test.ts` 断言这种 400 不重试。
+- 防复发：上述上限测试。
+- 相关记录：BUG-1325。
+- 复发自：无。
+- 修复版本：分支 `codex/rect-scoring-perf-20261013`，尚未合入 staging。
+