fix(reports): accept exact family birth time

docs/BUG_HISTORY.md

@@ -3509,3 +3509,17 @@
 - 防复发：服务器已经确定的 Skill 身份、指令和首个事实读取步骤不得再依赖模型自动选工具；所有 provider 调用前必须完成可审计的 Skill 绑定，首步工具面保持最小化，并继续以最终 `run.completed`、持久化 Turn 和计费不变量作为部署后验收标准。
 - 相关记录：BUG-177、BUG-198、BUG-206
 - 修复版本：本次 staging 发布候选（精确 SHA 以远端 staging 与健康检查验收为准）
+## BUG-209 | 用户选择准确出生时间后仍停留 reported，个人报告固定返回 birth_time_not_usable
+
+- 状态：resolved（本地候选，待 staging 迁移、精确 SHA 发布与登录态报告验收）
+- 首次发现：2026-08-16
+- 最近更新：2026-08-16
+- 影响面：初始化出生资料保存、账户资料编辑、`POST /api/reports` 出生时间可用性门槛、既有准确时间 Profile。
+- 用户现象：用户在初始资料明确选择“我知道准确出生时间”并填写具体分钟，资料与地点均完整，但生成个人报告仍返回 `422 birth_time_not_usable`。
+- 触发条件：Profile 保存为 `birth_time_source=family_exact`、前后误差均为 `0` 且有合法 `reported_birth_time`，但 `active_birth_time` 仍为空、`birth_time_status` 仍为 `reported`；报告接口正确要求 `accepted/confirmed + active_birth_time`，因此请求必然被拒绝。
+- 根因：账户资料写入逻辑把所有非引擎确认的出生时间声明统一降为 `reported + active null`，没有表达“用户明确采用自己提供的准确分钟”这一独立状态。初始化资料声明与报告事实门槛各自符合旧合同，但组合后准确时间永远无法成为报告可用时间。
+- 修复：账户资料应用层只对 `family_exact + 0/0 + 合法分钟` 写入 `active_birth_time=reported_birth_time` 与 `birth_time_status=accepted`，继续保留原始 `reported_birth_time`，绝不伪装为 `confirmed`；同一准确声明重新保存可修复既有 `reported`，修改已采用的准确分钟会同步新的 active time。带 10/15 分钟误差的 family 声明、approximate、period-only、unknown 仍保持 `reported + active null`，普通资料编辑仍不得覆盖 `confirmed`。新增 forward-only 业务迁移，仅回填无校正 Case、active 为空、状态为 reported 的严格 0/0 family-exact 记录；该迁移只进入 `frontend/supabase/migrations`，不污染 identity-only `frontend/db/migrations`。
+- 验证：账户回归覆盖新建、既有 reported 原样重存、已 accepted 分钟修改、confirmed/legacy confirmed 保护及所有非严格准确来源，13/13 通过；账户、出生时间 intake、报告 API 与报告入口聚焦测试 82/82 通过。PostgreSQL 全业务迁移测试实际执行新增 migration，验证严格 0/0 记录得到 `05:00:05:00:accepted`，10 分钟误差记录保持 `active null + reported`，1/1 通过；TypeScript `--noEmit`、目标 ESLint 与 `git diff --check` 通过。
+- 防复发：`reported` 表示用户声明但尚未采用，`accepted` 表示用户明确采用为当前排盘输入，`confirmed` 只表示引擎或校正流程确认；任何初始化来源语义变更必须同时覆盖 Profile 持久化、历史回填、报告服务端门槛和客户端入口，不得通过放宽报告接口读取未采用的 `reported_birth_time` 绕过事实边界。
+- 相关记录：BUG-125、BUG-196、BUG-197
+- 修复版本：本地未提交候选