fix(rectification): anchor candidate windows to civil dates across midnight

Carry explicit local date intervals instead of inferring the day from clock
order. Cluster width, delivery, adoption, and reports keep the actual civil
date; adopted date is stored separately from the reported birth_date.

Algorithm identity is scoring-9 / spec-v5. Scoring weights, confirmation
thresholds, and Skill version are unchanged. Isolated Linux final-3 gates
passed; four pre-existing Python failures remain. This is not a production
release.

docs/BUG_HISTORY.md

@@ -12971,33 +12971,36 @@
 
 - 状态：investigating
 - 首次发现：2026-09-20
-- 最近更新：2026-09-20
+- 最近更新：2026-09-21
 - 影响面：`candidate_contrast.py`、`decision_policy.py` 的簇范围与宽度。
 - 用户现象：跨午夜连续三个分钟候选组成的短簇，被表示为从当天最早钟点到最晚钟点，宽度扩成全天。
 - 触发条件：同一签名簇跨午夜，钟点字符串排序而没有候选日期或全窗序号。
 - 根因：签名聚类及 `_cluster_span()` 丢失日期，只用钟点决定首尾；这不是本轮 Dasha 日期修复新引入的行为。
-- 修复：本轮仅独立诊断，不改聚类或交付策略；另行修复单处理。
+- 修复进展：日期锚点任务已本地实现 ordinal 排序、真实 offset 计宽及声明 segment 内 envelope，Python 聚类/决策、TS credible union/plateau、transition/probe 与交付贯通；不连续段不补洞。算法身份更新为 scoring-9，历史不重标。三公开 AA 独立子进程同机 A/B 分数、矩阵、簇边界与确认门逐位相等。真实 native golden 经前端请求/推断/交付 SSR 验证；最终全量及部署待验，保持 investigating。
 - 验证：纯虚构最小探针沿 `build_candidate_decisions()` 实测一簇三个连续跨午夜成员被报为 1440 分钟。未涉及真实案例资料，未标 resolved。
+- 统一验收进展（2026-09-21）：final-1 隔离 Linux 快照前端3649/3649、真实DB56/56通过，诊断性三公开AA七项投影21/21零容差相等；Python广域338通过/11失败，其中4个既存失败、7个新增失败，quick未运行，整体验收未通过。新增项包括3个版本/回执契约失配及4个历史冻结身份拒绝；后者是更早BUG-981冻结记录不能代表当前实现时正确fail-closed，不是final-1停写后生产源码漂移。旧证据原样保留。Grok 接续：三合同测试独立复验34/34；新扩展身份补四模块后真实20/900重跑并派生 current contract；新最终快照 final-3 tsc/lint0、前端3649、DB56、quick通过、AA 21/21、Python广域352/4（0新增失败）。无部署/真人证据，保持 investigating。详见PROGRESS。
 - 防复发：后续需完整日期/相对窗序号回归贯穿签名聚类、候选决策与交付范围，不能只测试辅助 `_primary_cluster`。
 - 相关记录：BUG-623、BUG-624、BUG-639、BUG-981。
 - 复发自：未发现同症状既有记录；BUG-624/639 的范围断言仍在但均是同日样本，跨午夜诊断测试覆盖的是另一条聚类路径，未覆盖本路径。
-- 修复版本：未实施，见 `docs/tasks/PROGRESS-rectification-cross-midnight-20260920.md`。
+- 修复版本：`codex/rectification-midnight-date-anchor-20260920` 本地未提交实现，未推送/部署；证据及待验项见 `docs/tasks/PROGRESS-rectification-midnight-date-anchor-20260920.md`。
 
 ## BUG-983 | 凌晨申报窗口的候选日期锚点可能偏到次日
 
 - 状态：investigating
 - 首次发现：2026-09-20
-- 最近更新：2026-09-20
+- 最近更新：2026-09-21
 - 影响面：V9 搜索窗、`engineRequestBody()` 与 `_candidate_datetimes()` 的日期传递。
 - 用户现象：申报在午夜后的范围向前跨日时，生产候选中心可能落到申报日期的次日。
 - 触发条件：申报日内早凌晨分钟采用左右搜索半径，起始钟点位于前一天，而请求仍只传未调整的申报日期。
 - 根因：前端只传钟点范围与原申报日期，生产枚举将起始钟点绑定该日、较小终止钟点推到次日；候选日期本身已错误，helper 按候选日期一致计算并不能修正上游锚点。
-- 修复：本轮仅独立诊断，不越界修改开窗或既有枚举合同；另行立单。
+- 修复进展：按已批准 D1/D2/D3 传显式本地日期区间，凌晨申报锚在申报日、前半窗落前日；late_night 追问一次，未知/跳过保留同日两段。真实服务端 schema 回归发现新选项数字钟点被既有文案过滤拒绝，改中文钟点，未放宽过滤。D4 明确授权后新增兼容迁移，保存独立 active date/来源/实际候选 offset，原 birth_date 保留；report sampler 与 VedAstro 使用实际候选日期。SQL 采用权限合成测试不代表真实候选通过确认门；未修 IANA/DST。最终全量与部署待验。
 - 验证：纯虚构窗口探针证明申报中心候选与申报日期的日期差为 +1 日；不含真实用户资料，未标 resolved。
-- 防复发：必须从申报日/分钟经实际前端请求构建到后端枚举端到端校验日期，而非只验证钟点范围与“支持跨午夜”。
+- 补充回归：预冻结审计发现新widen wrapper仍会按baseline重猜日期，丢持久区间与D1侧别；真实DB红测复现后，限本单30000迁移修为普通分钟按持久绝对日期扩窗、D1允许集合服务端保存、C/skip缩到单段仍保留原允许两段。侧别冲突等拒绝必须全事务无写入；真实DB dossier/compute→评分service→score请求捕获验证日期保持，网络截停不冒充引擎评分完成。最终标准DB与统一门禁见PROGRESS，仍未部署。
+- 统一验收进展（2026-09-21 Grok 接续）：隔离 Linux final-3 全门 tsc/lint0、前端3649、DB56、quick通过、AA 21/21、Python 广域 0 新增失败。无部署/受控真人证据，保持 investigating。
+- 防复发：必须从申报日/分钟经实际前端请求构建到后端枚举端到端校验日期，而非只验证钟点范围与“支持跨午夜”；扩窗不得重猜日期或将未知缩窄结果伪作用户选侧。
 - 相关记录：BUG-098、BUG-198、BUG-979、BUG-981。
 - 复发自：未发现同症状既有记录；BUG-198 时段开窗与 BUG-098 枚举回归仍在但不校验申报日期中心。离线 holdout 已有前日中心保护，未覆盖生产请求链。
-- 修复版本：未实施，见 `docs/tasks/PROGRESS-rectification-cross-midnight-20260920.md`。
+- 修复版本：`codex/rectification-midnight-date-anchor-20260920` 本地未提交实现，未推送/部署；证据及待验项见 `docs/tasks/PROGRESS-rectification-midnight-date-anchor-20260920.md`。
 
 ## BUG-984 | 时段旧分数缓存不校验算法身份且聚合回执可能显示新版本