fix(quality): reconcile registry census with current codec callers

[huangruiteng]

The registry-I/O census is stale on current main (473263cbf), failing both the census and Goal-instance inventory checks and blocking downstream product PRs such as #5189. Reconcile the checked-in manifest with the existing codec callers: add the authority-archive and peer-host-route reads and update moved source locations.

Both added sites use the existing load_registry codec. No direct-I/O classification, scanner rule, test expectation, execution permission or runtime behavior changes. The existing generator owns this metadata; no additional abstraction or duplicate smoke is needed.

Validation: reproduced the two failing tests on clean main (7 other tests passed); the same two test files now pass all 9 tests, including direct-I/O and stale-site rejection. python scripts/generate_project_registry_io_manifest.py --check verifies 250 sites with no unclassified direct access. Public-boundary scan and diff hygiene pass. No frontend companion change is required because this only repairs the source census consumed by architecture tests.

Exact-head change-quality receipt is valid. Risk-based premerge passes all three direct checks and both selected canaries; no manual holds. This repairs the validation blocker only; it does not claim deployment of #5189.

[huangruiteng]

Approval conclusion (author-owned PR; GitHub blocks formal self-approval)

结论：APPROVE。未发现阻塞问题。评审 head 为 906a1fc0005882f879fae38cd906f1797d4a2b9f，基线为 473263cbfd7d877e058941c9a770de4c7953d3bd。本次独立执行了清单消费者、基线对照和错误输入验证；结论仅覆盖这次清单修复。

动机

主干的 registry I/O 清单遗漏了现有调用点，并保留了移动前的位置，导致清单完整性和 Goal owner inventory 两项测试失败。这个失配会反复阻碍正常开发验证。恢复清单与真实源码的一致性是一个完整、可独立验证的维护结果，也符合 Goal identity RFC 对复用既有 codec 与 I/O census 的要求。它不代表下游 #5189 已经交付，也不完成 identity enforcement。

改动思路

沿用现有生成器和 Python/TypeScript AST 扫描器，把源码作为调用点真相、JSON 作为可核验的生成清单。验证入口重新扫描 tracked product tree，然后检查遗漏、过期、重复、位置变化及分类。放宽扫描范围、删除完整性断言或另加扫描器都会掩盖问题；重新生成这一份清单已经足够。

还检查了最近集成的 #5173 与 #5183：它们分别引入 archive migration 路径和 peer host route 的既有读取。本 PR 收敛这些调用的 census，没有增加第二个 registry loader、状态 owner 或验证规则。保持源码变更后重生成、检查再提交的维护方式即可，无需附带新的抽象或 smoke。

具体改动

整个差异只有 project_registry_io_manifest_v1.json 一个文件，增加 24 行、删除 8 行；属于生成的架构验证数据。清单由 248 个调用点变为 250 个，原有九处 direct I/O 分类逐项保持相同，source policy 和 schema version 均未变化。

关键代码讲解

• archive 调用清单：handle_authority_archive_command 的 migration 分支在源码第 77 行读取 registry，export 和 audit 分支分别位于第 87、98 行。新增调用让函数内的编号顺延，所以不能把 #3 单独理解为新增了一条运行时 audit 行为。三个条目都对应真实的 load_registry codec read；authority_upgrade_roots 的三处位置也更新到现有源码。
• peer route 调用清单：补上 resolve_peer_host_route 第 65 行的 codec 读取；返回路由和投递授权仍由已有实现决定。manager_inbox 与 peers._goal 的条目只修正行位置。
• 校验入口：--check 使用 validate_project_registry_io_manifest 比较扫描结果与清单，失败仍输出具体诊断并退出非零。生成时复用上一份清单的 direct-access 分类；以当前清单为种子重新生成，所得文件与 head 字节一致。

对主干的风险

最值得反证的风险是“清单绿了，但漏读被藏起来或 direct I/O 例外被扩大”。我比较了两端的扫描器、生成器和相关生产调用源码，它们字节一致；扫描根、排除规则和九项 direct I/O 分类也都没有变化。清单里的 codec_api 是现有扫描器对真实 codec 调用的分类，不授予执行、迁移、投递或 Goal lifecycle 权限。CLI、App 与 Lark 的生产行为和配置入口未改变，因此这次无需 frontend companion 或开关迁移。

语义与CI对齐

独立验证结果如下：

• 相同两个测试文件在基线为 2 failed / 7 passed，失败均为上述 stale census；在 head 为 9 passed，保留了 direct I/O、过期及重复条目的负例。
• 同一份输入分别经过两端真实 generate_project_registry_io_manifest.py --check --output …：7 组、14 次执行。正确清单两端通过，旧清单两端拒绝；遗漏 peer 调用、重复条目、错误行号、错误 codec 分类及改变扫描范围的五种变异均被拒绝，完整诊断与退出状态一致。
• head 的 250 个调用点检查、带原分类的重生成比对、差异卫生和单个已签署提交检查通过。两项现有 maintainability / semantic-vocabulary canary 在基线与 head 都通过，规范化输出一致。
• 在当前完整范围重新记录并核验质量回执后，原生 premerge 实际执行的 3 项直接检查与 2 项 canary 全部通过，没有失败、跳过或 manual hold。变更文件的 public-boundary scan 无错误；检查中出现的两条本机 registry 健康提示与该文件无关。

依照当前评审配置，没有查询、轮询或等待远端 CI。这是本地验证结论，不宣称远端 merge-gate 已通过，也不执行合并。

我的整体评价

这次修复达到了明确的维护目标：消除已经复现的两处验证阻塞，同时保留拒绝错误清单的能力。范围与成本相称，已有生成器就是最小的修复 owner；相邻边界无需附加重构。剩余限制是静态 census 只证明现有扫描规则下的 tracked 调用覆盖，并不证明所有动态访问都能被识别，也不替代下游产品路径的独立验收。未来源码或 head 变化仍需要重新生成与核验。允许此 head 的评审通过，合入仍需遵守 maintainer 与 exact-head readiness 要求。

English verdict: APPROVE - 906a1fc. The generated census matches current codec callers without changing scanner rules or direct-I/O exceptions; 9 focused tests, 14 paired CLI checks and the native premerge gate pass. Remote CI was not consulted; no merge was performed.