Record the pins-layout change behind the test-pg failure

Why: the fail-loud assertion worked as intended and named the real cause -
RDM's pins set grew from four to six, so the CI step that checks out and builds
all three pins no longer sees a consistent layout. My prev_sha choice was
wrong and I did not check layout consistency when writing the unit.

Evidence: run 4711 job 7821 - 'rdm pin c6304224 的 pins/agent-system-frontend
未落地：缺少 go.mod'; pin layouts verified across all five commits; local
build-product.sh on the delivered head succeeds.

Impact: task card only.

Refs: PR #682

.task/fix-pal-component-delivery-pins.md

@@ -96,7 +96,29 @@ Development-Manager PR #32（`2c2e372`）为 `admit` 增加「权威基线内容
 
 已核实的成因：RDM `bc8db88` 的 `go.mod` 用本地路径 replace `agent-document-renderer => pins/agent-document-renderer`，因此其 `go.sum` 中**没有任何** agent-document-renderer 条目（实测计数 0）。Dev 侧构建会把 RDM 的 backend replace 重写到 `../backend`（即 Dev 的 `modules/backend`，当前 `f084d10`），而该 backend 直接 import document-renderer 的上述包，于是 RDM 的模块图无法提供对应条目。另注：RDM 自身钉的 backend 是 `bd640df`，与 Dev 的 `f084d10` 已分叉。
 
-这正是「只有真实组合门禁才能发现」的那一类不兼容——`make test` 全绿（exit 0）也照样漏掉。属跨仓组合问题，需要决定修法（Dev 侧注入 go.sum 条目 / 对齐两侧 backend pin / 调整 RDM 物化步骤），不宜在本 PR 内猜测实现，故如实标 blocked。
+这正是「只有真实组合门禁才能发现」的那一类不兼容——`make test` 全绿（exit 0）也照样漏掉。
+
+### 根因（已定位，非制品缺陷）
+
+同一份 RDM 在本地跑 `scripts/build-product.sh` **成功**（产物 `9ea3fcc8cef0df8a`），说明 RDM 制品无缺陷。报错只出现在 CI，原因是 **RDM 的 pins 布局从 4 个变成 6 个**（新增 `pins/agent-document-renderer`、`pins/agent-system-kb-regulations`）：
+
+| 提交 | pins 数量 |
+|---|---|
+| `legacy_sha` 72bb1fec | 4 |
+| 旧 `prev_sha` 3484ec2 | 4 |
+| 旧 `sha` c6304224 | 4 |
+| 新 `sha` bc8db88 | **6** |
+| bc8db88 的第一父 59b3624 | 6 |
+
+CI 步骤逐个检出并构建三个 pin，依赖三者布局一致。新 `sha` 是 6-pin，而 `prev_sha`/`legacy_sha` 仍是 4-pin，布局不再一致；本次 fail-loud 断言直接点名：`rdm pin c6304224 的 pins/agent-system-frontend 未落地：缺少 go.mod`。
+
+我先前把 `prev_sha` 设成旧 `sha`（c6304224）是错的——它是 4-pin 布局，且我在单元包与注释里都未核对布局一致性，这是本次返工的直接原因。
+
+### 未决（需决策）
+
+- `prev_sha` 应取 bc8db88 的第一父 `59b3624`（6-pin、与新 sha 布局一致、紧邻交付）；但这样 `prev_sha` 与 `sha` 仅隔一个合并，生命周期套件的「来回部署身份稳定性」覆盖力度下降。
+- `legacy_sha` 必须保持「无身份」语义，因而必然是老提交（4-pin）。构建循环是否应继续要求三个 pin 都可构建？若否，则该步骤对 `legacy_sha` 应放宽断言或单独处理——这属于 CI 步骤语义的设计取舍，不宜由实现侧默定。
+
 
 ### 其余验证