守卫单语缺口：「内置共享规则表」口径规则只读英文页，三语的另两份表无人检查

[yinlianghui]

在实现 #790 + #791 时发现，作为观察记录立单，不在该 PR 里顺手改 —— 那次的守卫扩面已明确限定为 OWD 表（全对象集）与相关列表表（中文两页），把第三条规则一并扩掉属于判据变更。

现象

test/sharing-coverage.test.ts 有三条读文档的口径规则，全部读常量 SHARING_DOC（英文页）：

1. the built-in rules table lists exactly the shipped sharing rules
2. every documented rule states the object, access level and position it really grants
3. the related-list table tells the truth about each account child

#790 的 PR 把第 3 条按语言另立了一份（describe('the related-list table names the same account children on the Chinese pages')），并把 OWD 表守卫扩到三语全对象集。第 1、2 条仍然只看英文页。

content/docs/administration/sharing-and-security.zh-Hans.mdx:87-95 与 .zh-Hant.mdx:87-95 各有一份同样的九行内置共享规则表，规则名是英文（Account Team Sharing 等），但对象列与授予列是翻译过的（客户 / 客戶、编辑 / 編輯、读取 / 讀取）。今天这两份表逐条核对下来与 src/sharing/ 一致 —— 九条规则、对象、访问级别、岗位全对。

为什么现在不是活的缺陷

上面这句是实测：本单立单前把两份中文表与 src/sharing/index.ts 逐行比过，零漂移。所以今天没有读者会踩到假规则表 —— 这是休眠的覆盖缺口，按 observation-class 归类（finding，不带 pm:queue）。

它值得记下来的原因与 #725 一样：这一类缺陷在本仓历史上真的以中文页形态发生过（#791 的整页口径漂移、#592 漏掉的 | Events | 行都是），只是碰巧这张表干净。下一次有人增删一条 sharing rule，英文页会被守卫逼着改，两份中文表不会。

可选的修法

#790 落地的 PAGES 表已经是「按语言 authored 的 RegExp / 字面量」这一套基建，ROW_LABEL 里也已有全部 17 个对象的三语标签。所以扩第 1、2 条只需要：

• 规则名列：语言无关，直接复用；
• 对象列：查 ROW_LABEL[rule.object][locale]，已有；
• 授予列：新增一张很小的 ACCESS_WORD: Record<Locale, Record<'read' | 'edit', string>>；
• 岗位列：反引号里的岗位名语言无关，直接复用现有断言。

即一张三行的新 ledger，不引入新风格。

Related: #725（同形状，docs-drift.test.ts 的磁贴散文规则）、#791。