docs: 同步信箱生命周期实现口径——§4 缺口收敛、水位空洞老化、回填事实并入 PROC_STATE

message-lifecycle.md：§4 两个崩溃窗口随"终态与回填意图同体同行"消除（不再是缺口，改为
说明剩余未闭环项是回填跨库单写期间的持续失败）；§5.1 补空洞老化规则（自增回滚空位会使
水位永久停摆，超出最大提交时延即判永久并放行，只跳过空洞不越过已存在的行）；§5.2 补判据
机制（不依赖独立待办表，R 覆盖退避）；§3 表格改回填意图与"到期或已达 NOW − R"。
design.md：§2.1 表以 INBOX_CURSOR 取代 BACKFILL_TODO、PROC_STATE 责任补回填事实；
§3.1 收报改为按 ID 区间扫描且不以标记为谓词；§3.3 终态由处理器事务内落库、死信同样可
补写；§6.1 维护作业改为 BackfillService.sweep；§7 补 max-commit-delay/overdue-backfill/
backfill-batch 与 mailbox.processed-value；§8 验证表补"终态未回填不得阻断发现"与"意图随
事务回滚"；§9 入口表更新；§10 缺口两则改写为现状与待确认项。
architecture.md：§4 主流程第 1/3/4 步与 §3 存储表同步（水位、回填意图、单事务范围）。
flight-state.md：§2 对象表同步。user-stories.md：US-01/US-09 当前基础与落点改为实现现状、
Q2 口径改为"老化阈值待库方书面承诺"。

docs/user-stories.md

@@ -42,7 +42,7 @@
 4. PG 不可用或批次中途失败时不改信箱标记；恢复后补建遗漏，记录失败次数与扫描进度。
 5. 较小 ID 迟提交、ID 有空洞、兼容入口先入队较大 ID 时，必须遵守经 Q2 确认的发现与顺序协议；不能用“最终会重扫”冒充严格 FIFO。
 
-**当前基础与落点**：`ingress/InboxPoller.kt`、`InboxEnqueue.kt`、`infra/persistence/jdbc/JdbcCminmsgInboxRepository.kt` 已有轮询与判重；固定 `afterId=0` 全量扫描，水位与补扫策略未实现（每轮顺带对账回填待办，见 US-09）。扩展 `InboxPollerTest`，补真实 PG/MySQL 中断恢复测试。
+**当前基础与落点**：`ingress/InboxPoller.kt` 按 ID 区间扫描（`ID > W`，不以处理标记为谓词），水位落 `INBOX_CURSOR` 并与入队同事务推进；`JdbcCminmsgInboxRepository.readRange/maxId` 与 `ProcStateRepository.insertIfAbsent` 承担发现与幂等入队。空洞老化阈值取 `pipeline.max-commit-delay`。剩余：Q2 未书面确认前，老化阈值与严格顺序仍是假定口径；真实 MySQL 的中断恢复与迟提交联合测试待现场环境。
 
 **前置**：共享库读契约；Q2 决定严格顺序的端到端验收。水位与扫描谓词口径以 [message-lifecycle.md](message-lifecycle.md) §5.1 为准。
 
@@ -190,7 +190,7 @@
 4. 重复补偿效果幂等，保留稳定的完成时间与审计；重放后的新处理结果不能被旧回填任务覆盖。非法报文缺 META 时也有明确回填方式。
 5. 影子模式禁写，双跑仅一个系统持有标记写权；暴露 PG 终态、回填状态、积压、最老年龄与持续失败告警。
 
-**当前基础与落点**：回填意图已在业务事务内预登记到自有 `BACKFILL_TODO`；提交后同步回填（写 `DATE_PROCESSED` 与 `PROCESSED`），失败由 `BackfillSweepJob` 到期重试（每 30 秒、指数退避）。剩余缺口：缺 META 或解码失败的死信回填方式，以及“待办落账后再失败 / 提交后崩溃”两个窗口的补偿闭环。
+**当前基础与落点**：回填意图与处理终态同体同行（`PROC_STATE.BACKFILL_*`），随业务事务提交，`BACKFILL_TODO` 已随 V2 迁移下线；提交后立即尝试一次，失败由 `BackfillService.sweep` 到期重试（每 30 秒、指数退避 30 秒起步封顶 15 分钟），接收时间超过超期期限 `R` 时强制补写（§5.2）。死信同样可补写——回填只需消息 ID，不依赖 META。剩余：Q7 的标记值集与写权限书面确认；影子环境禁写尚未实装。
 
 **前置**：US-03 终态接口；Q7、共享库更新权限。覆盖四类终态、事务回滚、重复补偿和重放竞争；生命周期、超期补写与清除口径以 [message-lifecycle.md](message-lifecycle.md) §4/§5.2/§6 为准。
 
@@ -305,7 +305,7 @@
 | 编号 | 问题与当前口径 | 解除阻塞的产物 |
 |---|---|---|
 | Q1 权威存储（方向已定） | 当前 PG 单库权威，主表 + 无损明细；现场供库目标为 Oracle 11g。 | 单库决策已采纳，Oracle 完整适配与部署验收仍待交付；不得退回 Redis 双写。 |
-| Q2 入队顺序 | 水位+补扫无法自动保证较小 ID 迟提交不越序；当前有限批扫描也可能被未回填记录挡住。 | 库方 ID/提交顺序约束，或明确的发现完整性与暂停/恢复协议；晚提交、空洞、兼容入口与重扫联合测试。不能凭空假定 ID 连续。 |
+| Q2 入队顺序 | 空洞老化阈值取自"最大提交时延"，但库方尚未书面承诺 ID 单调与提交时延，因此迟提交不越序仍无端到端保证。 | 库方 ID/提交顺序约束，或明确的发现完整性与暂停/恢复协议；晚提交、空洞、兼容入口与重扫联合测试。不能凭空假定 ID 连续。 |
 | Q3 HTTP 契约 | 目标 ResponseDto 与现有 text/plain ID 不同；请求媒体类型目标已列出，错误码、状态码、查询格式等仍需对拍。 | 每个保留接口的真实请求/响应样例、错误表和契约测试；10MB 的字节口径、字符集及兼容变更说明一起固定。 |
 | Q4 Kafka wire | 当前 msg/schd 均按 `FLID` 逐航班发送（schd 由 `flushSchd` 合并为每个 FLID 的最新状态），与 legacy“多 FLID 数组”形态不同；msg 是否需按 `SNDR` 分区尚未接线。 | 下游确认发送粒度、key、去重标识放置、分区内顺序及批次确认策略；未定案前不改动现役消费契约。 |
 | Q5 请求匹配 | 目标优先 SEQN 回显，但回显是否可靠需确认；DTTM 降级存在跨代误匹配，尤其旧应答到达新请求期间。 | 15 类请求/响应样例、回显字段与时间格式；降级风险是否接受及拒绝条件。默认超时仍为 RQFD 60 秒、RQRD 30 秒。 |