feat(grok): 把 #826 的 strict repo-read 共存档位落到 main

[vansin]

grok 栈 #825 → #826 → #830 → {#836, #867} 的第二层。#825 已由 #1004 落地
（main 89a6164e，#825 已关并在上面写了去向），所以这一层现在可以直接对 main 落。

没有 force-push #826 那条共享 draft 分支 —— 本 PR 从我自己的分支发。

rebase 方式：只取它自己那两个提交

直接 git rebase origin/main 会冲突，冲在 436b4bdb fix: fail closed on broken Grok CommHub MCP —— 那是 #825 自己的提交，已经以 squash 形式在 main 上了，而 #826 的
历史里还带着它。

正确做法是把它自己那部分接到 main 上：

git rebase --onto origin/main <#825-head> <#826-head>     # rc=0

它自己的两个提交：

44968358 feat(grok): add strict repo-read copresence profile
11496762 docs(tests): record restacked Grok repo-read evidence

结果：12 files changed, 284 insertions(+), 36 deletions(-)。

今天这套门抓到一处

doc-symbol-pins：docs/message-lifecycle.md 把 shouldSkipMessage 钉在 cli.ts#L4662，
而本层又往 cli.ts 加了行，真值变成 4669。文本和 URL 两处都改。

🔴 这是同一条 pin 今晚第二次漂 —— #1004 刚把它从 4639 改到 4662，现在又要改到
4669。往 cli.ts 这种热点文件钉行号，几乎每个碰它的 PR 都会把它顶漂。
改成只钉符号、不钉行号才是根治，但那是另一条改动，不在这里顺手做。

其余门

test-suite-registration   rc=0   suites=198 registered=34 orphans=164 baseline=164 new=0
doc-source-pins           rc=0
no-escaped-comments       rc=0
no-memory-slugs           rc=0
home-path-baseline        rc=0
public-script-safety      rc=0
l1-paths-sync             rc=0
copresence-profile-pin    rc=0

合并之后

栈还剩 #830 → {#836, #867}。会照同样方式逐层往上落：
本地 rebase --onto 取它自己那部分 → 跑今天这套门 → 从我自己的分支发 PR → 不动原分支。

[chatgpt-codex-connector]

You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard.

[vansin]

🔴 更正我在本 PR 正文里写的那句「根治」

正文里我写：

改成只钉符号、不钉行号才是根治，但那是另一条改动，不在这里顺手做。

这句是错的，撤回。 我在动手前先量了一下，结果否定了它。

那道门的 PIN 正则（scripts/check-doc-symbol-pins.py:37）原文：

PIN = re.compile(
    r"\[([^\]\n]{1,120})\]\("
    r"https://github\.com/sleep2agi/agent-network/blob/"
    r"([0-9a-zA-Z._-]+)/([^\s)#\"']+)#L(\d+)\)"
)

它要求 #L<数字>。 去掉行号的链接根本不会被这条正则匹配到 —— 不是「换一种判法」，
是整条 pin 从这道门里消失。

实测（把 docs/message-lifecycle.md 那条 pin 的 #L4662 去掉，再跑同一道门）：

改之前     扫到 15 个 pin，判定 5 个     rc=1（漂移 1 个）
去掉 #L    扫到 14 个 pin，判定 4 个     rc=0
还原后     扫到 15 个 pin，判定 5 个

⇒ 它会「变绿」，但不是因为修好了，是因为不再被检查。 而且这道门真正判定的只有
5 条（另外 10 条是 skipped），删掉一条等于砍掉判定集的 20%。

那正确的做法是什么

目前就是现在这样：保留行号，让它漂、让门抓、在同一个 PR 里改掉。
这两次（#1004 的 4639→4662、本 PR 的 4662→4669）都是门正常工作的表现，
不是需要被消除的噪音 —— 代价是碰 cli.ts 附近的 PR 要顺手改一行。

真要减少这种 churn，得改门（让它也认「文件链接 + 锚文本点名符号」这种无行号形态，
并把它计入判定集而不是 skipped），而不是改文档。那是一条独立的、需要自己见红/见绿
证据的改动，我不在这条 PR 里做，也不再把「改文档去掉行号」当成方案。

教训：我差点提交一个「让门变绿」的改动，而它变绿的机制是把被检对象移出取集。
这和今晚反复出现的那个形状是同一个 —— 分母悄悄变小，输出和真绿逐字相同。