docs(qa-checklist): correct two knownGaps that still deny the provisioning.use resolve

[os-zhuang]

Fixes#10809

Two knownGaps clauses stated that the validator does not resolve provisioning.use
in either direction. The area-scoped resolve landed with the gap-1 work on #10593, so that
is false today: a same-area useresolves, and a cross-area one fails. The clauses
also still cited the old deferral (#7716 / #7720) as if it were live.

The inversion matters more than a stale footnote. The clause reads as permission: an
author following it would spell a cross-area use and get a red they were told to expect
not to get. A stale permission outranks a stale fact, which is why this is corrected now
rather than folded into the pending convention work.

What changed

file	what	revision
areas/records-forms.json	item records-forms.crud-roundtrip → its own fixtures.knownGaps[0]	5 → 6
areas/search.json	area-level recipeqa-contributor-bound-member → knownGaps[0]	(recipes carry no revision)
areas/search.json	item search.rls-both-personas — revision pin only, own fields unchanged	4 → 5

Both clauses keep their first half (the mechanism is AREA-SCOPED — still true and now
load-bearing) and state what is enforced today. The cross-area spelling is deliberately
not predicted: that convention is the open half of #10593, still undecided, and writing a
guess into a checklist is how the next stale permission gets created.

One correction to the card

The card places the sibling clause on item search.rls-both-personas. It is actually on the
area-level recipeqa-contributor-bound-member, which carries no revision/history —
the lifecycle check in scripts/check-platform-checklist.mjs is item-scoped, and none of the
four recipes in this checklist has either field. So the "both items owe a revision bump"
obligation was re-derived rather than applied literally: search.rls-both-personas is bumped
because it uses that recipe, making its revision the only pin a run record can hold the
recipe text against. Its own steps, clauses, fixtures and provisioning are unchanged, and the
history entry says so explicitly, so no run verdict is invalidated.

Verification — this gate is not CI-wired

check:platform-checklist is not wired into CI, so a green Lint & Repo Gates on this PR
says nothing about it. Both halves were run by hand at af2e9ee9b4, before and after:

✓ checklist-select self-test: 17 cases pass.
✓ check-platform-checklist --self-test: 36 assertions — … `fixtures.provisioning.use`
resolves against its own area and fires on a dangling one.
check-platform-checklist: OK — 15 areas, 205 items (205 active); … provisioning: 4 area
recipes, 6 item references resolved (self-checks: 22 trap-vocabulary + 14
provisioning-resolve assertions).

Invariants are identical to the pre-edit baseline (205 items, 4 recipes, 6 references resolved).

Ablation — to show the revision bump is enforced rather than assumed. Predicted before
running: exactly one reddened case naming the item. Reverting crud-roundtrip to revision 5
while its history's last entry stays 6 (mutation proven on disk: target anchor 1 → 0,
replacement +1, and the parsed field read back as revision=5, last history=6):

✗ records-forms.json · records-forms.crud-roundtrip: "revision" (5) must equal the last
history entry's revision (6) — a semantic edit bumps both (exit 1, 1 case)

The restore leg was run too: byte-identical to the commit, all three halves green again.

Derived gates (scripts/pm/dispatch-gates.mjs, 2 paths) and the hand-run scripts/** pair:

✓ doc authoring guard: 389 files clean — no bare metadata literals.
✓ check:doc-formula-expressions: 22 record-scoped formula example(s) across 416 files /
1444 TS blocks judged clean by @objectstack/formula.
✓ check:entry-guard: 129 scripts/ file(s) — every entry guard goes through invoked-as.mjs.
✓ check:parse-guard: 128 scripts/ file(s) — every TypeScript parse goes through ts-parse.mjs.
check-nul-bytes: OK (scanned 6295 text file(s); no raw ASCII control bytes).

No changeset

skip-changeset: nothing here is published. content/docs/ is the docs-site source; these
files live in docs/qa/, which no apps/docs or content/ path references and no
package.json ships.

---

Generated by Claude Code

[github-actions]

⛔ merge queue 构建失败 — 先分诊，再决定要不要重排

队列构建 32500800720 红了。队列跑的是全量套件（PR 侧 CI 只跑 affected 子集），
所以失败的测试可能在本 PR 没碰过的包里 —— 那不是重排能修的。每次盲目重排都会让排在后面的所有 PR 重建一轮。

失败的 job（日志抽取，best effort）：

• Console Pin Gate — 失败步骤: Build the Console SPA at the pinned objectui SHA

  ✗ Build failed in 5.88s
  

↳ 失败原因 是判读的关键：超时（Test timed out in … / Hook timed out in …）多半是负载/时序，不是本 PR 的回归；
断言（AssertionError: …）才指向真实的行为改变。两者的 FAIL 行长得一模一样，只有这一行能区分。

跨 PR 相同签名（24h，按失败测试文件聚合）：

• ⚠️本次没有可用的聚合签名（日志里没有能解析出测试文件名的 FAIL 行）—— 这不是「没有同签名的其他 PR」，是这一轮没测到。跨 PR 聚合本次不可用，请手工比对其他 PR 的同类评论。
• ⚠️ 24h 评论账本没读完（超过 5 页仍未读到窗口尽头），所以上面的「不同 PR 数」是下界，不是全量。

历史信号：

• 本 PR 过去 24h 无队列失败记录（首次）。
• 过去 24h 队列共有 31 个失败构建（不含本次）。

分诊清单：

1. 失败测试在本 PR 改动的包里 → 真回归，修 PR。
2. 失败测试与本 PR 无关 → 看上面的「跨 PR 相同签名」；已有汇总 issue ⇒ flaky/环境问题实锤，去那张 issue 上谈，修好前重排只会再烧一轮全队列。
3. 两者都不是 → 可能与同组 PR 语义冲突；等前面的 PR 落地或失败出队后再重排一次即可，不要连续重排。

---

Generated by Claude Code · merge-queue-triage workflow (#4859)