fix(chat): skip idle recovery of completed commands

[loopx-agent]

Completed Chat commands such as /stop, /status, and /help can still be awaiting their provider reply. Core recovery has no execution left to resume for these rows, but previously performed another App identity query on every reconciliation. Skip that idle recovery step when commission adoption is not pending; the delivery owner still freshly verifies the binding, identity, source, and original topic before returning the reply.

Validation:

• 128 native Chat/Lark transport and binding tests passed. Three new command regressions fail on the base and pass with this change; the former completed-command probe expectation was updated while retaining its disconnect/no-return check.
• Complete file-backed reconciliation with the public synthetic provider: identity queries decrease from 6 to 5, the same single topic reply is verified, and an unavailable identity still blocks delivery. Pending commission adoption retains its identity check.
• Premerge validation passed all 5 direct checks and both selected architecture/semantic canaries. Diff and public-boundary scans are clean.

This is a bounded recovery overhead reduction. It does not establish a live acknowledgement latency SLA; installed-service qualification remains separate. The existing Core/transport ownership stays in place, without introducing an identity cache or another status contract.

[loopx-agent]

Approval conclusion (author-owned PR; GitHub blocks formal self-approval)
Reviewer: model_agent · gpt-6.1-sol · OpenAI · runtime_reported · reasoning_effort=xhigh

动机

在绑定 Chat 或飞书话题里请求 /status、/stop、/help 的用户，可能正在等待一条已完成命令的原路回复。
原命令已经持久完成，每次等待回复的恢复仍多查一次 App 身份；当前跳过这次空恢复查询，把正式发送前的身份和来源核验留给已有投递 owner。
三个命令的完整文件存储回传对照都从 6 次身份查询降为 5 次；身份不可用或来源变化仍零发送，恢复后在原话题只返回一次，原 Core 记录只增加送达确认。
此修复不增加身份缓存、队列、协议或权限，不证明真实飞书、已安装 App、手机旅程或实时回复延迟 SLA。

改动思路

Core 恢复复用既有完成状态和 adoption 标志，正式投递继续由原 transport 核验身份与来源；不增加缓存、队列或第二个权限 owner。
当前交付已完成命令的恢复开销修复；待采用委托、活动执行和原路投递仍由原 owner 负责，真实飞书与安装验收保持独立。
这不是把完成状态当成已送达：Core request 只有原命令结果，transport 仍在真正发送前解析当前 binding、读取原消息及话题并核验来源，最后才保存投递确认。缺少执行债务时重复查询并不提供新授权。现有 Python 文件/运输编排 owner 足够处理这五行 guard；新建身份缓存会引入撤销和失效责任，另造状态或队列反而增加维护成本。没有新增能力开关、用户确认步骤或前端入口。

具体改动

精确 head：84e6715b703aca1bd107b37dc0e0f3a84f8e3bb8。不可变变更前规格 spec_ref=docs/architecture/rfcs/app-conversation-and-async-inbox-v0.md，spec_revision=3593cf17dada74b807719ba4fdbbb1738fa0a56c。

• Private Chat status and help: scoped observations：implemented，原观察快照、请求与 Session/Turn 保持，不为命令恢复启动模型或新 Goal。

• Bound steward private Chat: explicit new commissions：implemented，待 adoption 的原操作仍走身份/回执核验，通知不能替代范围采用或结算。

• Authority：implemented，失效身份、撤权或来源变化继续拒绝发送，恢复只返回原路。

• recover：在既有 delivery_verified 早退之后，仅 command_completed 且 commission_adoption_pending 不为真时直接继续。prepared、command_queued、accepted 和 adoption pending 的原检查/恢复分支保持，复用已有状态而非新词汇。

• reconcile_request：唯一生产恢复调用者没有把 recover 的 None 返回当授权；之后仍解析原 binding，正式 _deliver 经现有 intent/readback 及 source verifier，成功才 record_delivery。已确认送达再次 reconcile 不重发。

• _source_message：原消息、App、受众与话题关系继续现场读取，外来 chat 不能借已有命令结果成为目的地。
  完整 diff 仅两文件 +51/-2：生产五行含注释，三个命令的聚焦参数化回归，以及原“恢复会查询 App”测试改名和期望变更；后者保留 disconnect/no-return 断言。PR 明确披露恢复默认少一次查询，不改变 UI、设置、CLI 入口或协议。

对主干的风险

独立运行四个相关 Chat/Lark binding、private compatibility/Agent 文件，135 项通过、零跳过，143.94s。三个新测试对不可变 main 的真实实现全部失败于多出的 auth 调用（3.22s），当前全部通过（3.30s）。独立生产文件 store、Core journal 和原 reconcile 路径搭配公开合成 provider/fake Codex 协议，对 /status、/stop、/help 各做完整基线/当前对照：idle auth 1→0、完整健康回传 6→5，其余记录的业务字段相同。每臂都直接验证原 Core 文件在发送前字节不变，完成后只增加 delivery_verified；未宣称跨臂随机 ID、时间或物理路径整包相同。
将 adoption pending 置真，两臂均仍核验身份且不改变该原记录。bot 身份不可用或原消息变成外来 chat，均零发送且不写送达确认；恢复原身份及消息后只有一条回复，落在同一原话题，重复 reconcile 零新增发送。原撤权测试继续保留。测试边界是实际本地存储与运输逻辑、合成 provider；没有真实飞书发信、付费模型、已安装服务或手机验收，也不把查询计数等同于回复耗时、CPU 或账单改善。

语义与 CI 对齐

当前 diff advisory 先于完整 premerge；5 项直接检查及两项架构/语义 canary 实际通过，零失败/人工 hold，实际候选路径的公开边界检查通过。DCO 已签署。现有 completed/adoption/delivery 状态复用，没有子串分类或平行 Python 权限决策；原失败恢复与正式发送的机器义务没有被降为提示。没有查询、轮询或等待远端 CI。

我的整体评价

APPROVE。这完整交付了既有完成命令恢复的有界开销修复，减少反复 IO，同时保留原路核验、失败纠正和一次回传。未来方向检查认为现有两个早退与原投递 owner 足够清楚，再合并布尔式或抽 helper 没有实际收益；较大的通用 journal/TS 迁移仍由原 RFC 路径负责，不在此新建仪式后继。真实服务、模型、手机及长期 SLA 继续独立未验。发表后另核 closeout/readiness，不据源码批准推断合并或讨论处置权限。

English verdict: APPROVE 84e6715b703aca1bd107b37dc0e0f3a84f8e3bb8. Three production-file/provider journeys reduce idle identity queries 1→0 and full reconciliation 6→5 while preserving pending-adoption checks, unavailable/foreign-source refusal, original-topic correction and exactly one return. All 135 focused tests and 5+2 premerge checks pass. Synthetic provider/native-protocol fixtures do not qualify live Lark, installed/mobile behavior or a latency SLA.