最小修复方案与验收

本轮只给编码入口和验收，不修改运行逻辑。

P0：让完整模型结果先保存，再决定是否能执行

修改集中在 JevSemanticReview.resumeRetained()、consumeCache() 和 Ledger source binding：

• 保留现有 State/Concrete/Witness 身份检查，但把“可保存决策”和“当前 GUI 可执行”分开。
• 消费前允许使用已有 State 演化/GUI 重定位证据恢复当前 Candidate；无法唯一重定位仍 stale。
• 对已通过 Pairwise/历史校验的结果，先 putBeforeDeadline() 到现有 Ledger，并保存原始 source State/Concrete/Witness/input fingerprint；当前 GUI 不同只影响 executable()/navigation。
• 不把全局 confirmationCount 或无关 State 的 revision 作为硬失效；改成按参与该 Candidate/Witness 的相关 execution revision 检查。
• 不放宽 ConcreteActionIdentity、exact execution、enabled、correspondingNode 或 navigation mask。

验收：复用现有 SemanticLateResultTest/SemanticAsyncLifecycleTest，新增真实归档离线回放：semantic-115 必须保持 stale（若无法证明身份），semantic-66 只有 lineage+相关证据同时通过才可复用；semantic-32 类完整 HTTP 200 + PROMOTE 必须进入 Ledger，但不自动执行。

P1：多数决只改路由入口

修改 JevSemanticReview.allMatchedExecuted() 的调用边界，保留现有 Candidate 打包和 Pairwise：

• 对实际提交 Candidate 逐个计算 A（Registry 相关 Concrete 且有确认执行）和 S（未匹配/UNKNOWN/歧义）。
• A>S 异步，A<S 同步，A=S 异步。
• 把 A/S、candidate IDs 和 routing decision 写入 SEMANTIC_REVIEW_ROUTED，否则离线无法验收。

验收：单元 fixture 覆盖 A/S=3/0、2/1、1/1、1/2、0/3；真实回放必须对 3121 个请求逐条重算，UNKNOWN=0 才能宣称“多数决减少同步”。

P1：取消未发送 stale retained 请求

优先改现有 JevTransport/Gateway 取消传播，不建新调度架构：

• Native 判断 retained request 已 stale 且尚未获得 sent_at 时，发送可关联 request_id/body hash 的取消。
• Gateway queue 释放前不占用 provider lease；已 sent_at 的调用保留审计，不静默删除。
• 在现有 queue 中给同步请求优先级，异步仍共用上限/14 RPM。

验收：离线/loopback 检查 received_at→cancel_at→sent_at 三种时序；真实审计要求 queue timeout 中“all matching stale/cancelled”显著下降，且不能丢失原始 receipt。

P2：完整 5 秒边界可见化

若论文口径要求“APE 整轮审核最多 5 s”，修改 central deadline 使用位置，而不是只改 await()：

• 保留 provider_wait_ns 统计。
• 另设 whole_review_deadline，把锁、prepare、HTTP、consume、Ledger publish 都纳入同一 deadline。
• 超时仍 fail-open，但写明 whole_review_deadline，不能把本地超额算成 Provider 超时。

验收：故意延迟 prepare/lock/HTTP 的受控 fixture；provider_wait<=5s 与 whole_review<=5s 分别可验证，不能只看一个字段。

不做的事

不改 Pairwise prompt/聚合/PROMOTE 门槛，不恢复 RN≥3，不新建 State identity 算法、第二套 Ledger/Probe cache、导航系统或多用户调度器。