fix(pr-review): recover capped file inventories with exact Git evidence

[loopx-agent]

GitHub caps the PR file API at 3000 entries, so a larger PR could keep the native review queue incomplete even after increasing the queue limit. Recover only from existing exact Git objects in the intended repository, reconcile API-confirmed rename pairs, and require file count plus whole textual additions/deletions to agree with fresh remote metadata before and after recovery.

Known API rows keep their statistics; unobserved binary counts remain unknown. No automatic Git fetch/clone/checkout, external diff or textconv is introduced. Missing objects, ambiguous mappings, malformed data or remote drift remain incomplete. Ordinary complete API reads and unversioned approval-closeout callers preserve their contracts. The bounded helper extraction stays inside the existing GitHub source provider; no new capability, setting or generic decision owner.

Validation

• 469 related tests passed; 43 existing optional live reasoning probes skipped. Focused source/scan/closeout tests: 124 passed.
• Both decisive recovery fixtures fail on the unchanged base and pass on this head. Real Git fixtures include an advanced base branch, rename, binary files and NUL-safe unusual paths.
• Fresh isolated wheel: 40 focused tests passed, source bytes matched the checkout, and the actual source CLI recovered PR refactor(quota): resolve fallback advice from one typed snapshot #4061 at db367de7bf90aefe59bcc0e06d6b0b0eb6583149 with 4028 files and matching aggregate totals.
• Current complete open queue: 47 PRs, zero detail failures. This establishes inventory completeness, not approval of those PRs.
• Native risk-based premerge, semantic advisory, Ruff, compile/diff hygiene and public/private boundary checks passed. No CI was queried or awaited.
• Source provider, its README and focused validation are the only changed surfaces. Runtime merge remains with the maintainer; global installation qualification follows merge.

中文：修复大 PR 的文件 API 截断导致队列一直 incomplete。仅使用已存在的精确对象，核对仓库、rename、文件数、全 diff 文本总量和前后版本；二进制的未知逐文件行数保留 null，失败继续明确 incomplete。真实 CLI、新 wheel 及完整队列已验证，不代表已完成 #4061 的评审，也不扩大撤回 review 或合并权限。

[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
Exact head: d747192a0526120c4ed2ceefee0363d4fc827c9c. Whole PR base: bca2fd6c2b3f68925f5b8dd5443d7b61667d2512. This is the author's published self-review, not an independent human approval.

动机

审阅者通过原生 PR 队列选择待审工作，遇到文件数超过 GitHub 文件 API 上限的大 PR。

旧版在 3000/4028 个文件处停止，整个公开队列被标记为不完整，扩大 PR 数量上限仍无效；修复后有足够精确本地对象时恢复清单，缺证据时仍明确 incomplete。

真实 source CLI 和新 wheel 恢复了同一精确 head 的 4028 项，47 个公开 PR 的完整队列读回无 detail failure。

本次交付是文件来源完整性修复，不代表已经 review 或批准 #4061，不增加 Git 抓取、发布、撤回 review 或合并权限。

全局安装仍需维护者合并后更新并读回；没有精确本地对象或不能核对总量时继续保留 incomplete，approval closeout 仍要求完整 API。

改动思路

仓库与 GitHub payload、Git 对象及 rename 证据属于现有 GitHub source provider IO；队列资格、排序、review 和 closeout 权威继续由既有 owner 管理。

当前 PR 交付可独立验证的完整清单或明确 incomplete，覆盖真实 CLI 与 wheel；维护者 merge 和全局安装属于下一集成门，不把较大的 #4061 评审捆入本修复。

依据已接受的基线能力说明 loopx/capabilities/pr_review_queue/README.md，版本 bca2fd6c2b3f68925f5b8dd5443d7b61667d2512。SOURCE-COMPLETE 对应新鲜完整 source 与失败仍 incomplete；SOURCE-READONLY 对应原命令不产生 review/merge/quota/Todo 写；SOURCE-OWNER 对应元数据与真正评审、closeout 决策分离。这些标签指向既有段落，不增加 RFC 准入条件。三项通过实际 caller、反例和读回验证。

增加扫描上限无法绕过 GitHub 单个 PR 的文件 cap，直接用 Git rename 相似度也不能保证与 API 相同的清单。因此只在既有 provider 中补两个私有 helper，保留原 REST caller。没有新能力、设置、第二个爬虫或 Python 通用决策 owner；provider IO 留在 Python，队列策略仍由既有类型化 owner 决定。

具体改动

完整 diff 共三项：provider 138/-25、语义测试 251 行、README 30 行；没有生成物、私有状态或 UI 修改。

• _read_git（loopx/capabilities/pr_review_queue/github_source.py:67）只读本地对象，禁用 replacement objects、lazy fetch、optional locks，子进程最多 30 秒。diff 明确禁止外部 driver 和 textconv；真实恶意配置 marker 反例未执行外部脚本。
• _recover_git_pr_files（:77）验证 origin 与目标 GitHub 仓库、完整 commit OID、唯一 merge base。--no-renames 加 NUL 格式保证带空白、换行和 tab 的路径不被切断；只对 REST 已确认的 rename 验证旧 D/新 A 及端点唯一性后折叠。文件数和文本增删总量必须与当前远端相符。
• _fetch_complete_pr_files（:161）对声明超过 3000 项且带精确快照的路径，在分页前及恢复后核对 head、base、文件数和增删量；任何漂移、缺对象、rename 歧义或损坏统计继续 incomplete。旧 closeout 无 snapshot 的调用和普通完整 API shape 保留。
• API 已知行保留原统计，未观测 Git 二进制行保留 null；Git 文本总量排除二进制文本行，不能把未知行数写成 API 0/0，也不能要求混合展示行数相加等于远端 aggregate。来源 provider 的恢复行注明 github/git；现有队列只是完整性消费者，不授予批准资格。

当前验证	结果与边界
source/scan/closeout 与相关能力	focused 124 passed；related 469 passed，43 个既有可选 live 模型推理 probes skipped
同一固定真实 Git fixture 在 B/H	B 的两个 source-complete 断言失败；H/wheel 的 42 项通过。实际对象和 fixture manifest 相同，覆盖先进 base、rename、NUL 路径、binary、新 head、元数据漂移、错误总量和 API 顺序
fresh wheel	与 checkout 的 source bytes 完全相同；40 项 focused 加 42 项固定自审控制通过，site-packages 来源已核对
真实 GitHub 与 production CLI	#4061 精确 head db367de7bf90aefe59bcc0e06d6b0b0eb6583149：4028 文件、+617493/-92453；source 和 wheel 独立完整读回；当前完整 open queue 47 项、零 detail failure
仓库验证	native premerge 15 selected + 5 direct checks 通过，无 manual hold；Ruff、diff、compile、公开边界和全树语义检查通过

保留修正前失败：第一轮真实 CLI 仍 incomplete，原因是初始计划把全部 binary 输出拒绝，真实 PR 却有 92 个有效 -/- 行。随后仅允许成对有效 binary 行并保留未知计数，新增真实 binary commit 反例，文件数/文本总量/版本门均保留；当前 source/wheel 读回证明该问题已修复。第一次 advisory 把 tests 路径传给仅支持 loopx source 的参数而失败，正确 tracked provider probe 与完整 semantic premerge 已通过。没有隐去历史失败，也没有用通过的模板证明模型推理提升。

对主干的风险

自动恢复仅在版本化的大型截断 source 路径增加本地 Git 读取和两次远端快照核对；普通 complete API 与不带 snapshot 的 closeout 保留原行为。正确对象不存在、origin 不符、总量不一致或未确认 rename 时继续 incomplete，这是明确剩余边界。GitHub 分页成本仍在，Git 读取有超时；没有后台 fetch、写入状态或模型调用。

相邻的未来维护边界已收敛为同一个 provider 中的只读 IO 与 immutable reconciliation helper，避免第二个队列/closeout 权威；不需要扩大为通用框架或无关 TS 改写。现有 frontend/config 操作没有新增能力或设置旅程；实际 caller 是已经出厂的 source CLI，且 wheel 已运行。

我的整体评价

仓库与 GitHub payload、Git 对象及 rename 证据属于现有 GitHub source provider IO；队列资格、排序、review 和 closeout 权威继续由既有 owner 管理。

当前 PR 交付可独立验证的完整清单或明确 incomplete，覆盖真实 CLI 与 wheel；维护者 merge 和全局安装属于下一集成门，不把较大的 #4061 评审捆入本修复。

未发现当前阻塞项，批准这三个文件的有界源码修复。精确 source recovery、反向权限/执行测试、固定基线缺陷对照、fresh wheel 和完整队列提供了可复核证据。GitHub 不能对本人账号作者的 PR 做 formal self-approval，因此此结论是 COMMENTED 自审记录；不声称 aggregate 已 APPROVED。runtime merge 仍由维护者处理，全局安装随后验收。未查询、轮询或等待 CI。

English verdict: APPROVE - At d747192, the capped file-source repair is justified in the existing GitHub provider. Exact repository/objects, API-confirmed renames, count/textual totals and pre/post remote fences restore truthful completeness while invalid evidence stays incomplete. The same immutable Git fixture fails both decisive assertions at base and passes 42 controls at head/wheel; 469 related tests, a fresh wheel, actual 4028-file source readbacks, the complete 47-PR queue and native premerge pass. Forty-three optional live reasoning probes are skipped; no model improvement, full #4061 review, global installation, formal self-approval or merge authority is claimed.