[docs] (P7): ID-P7-28 - package D3 landed; the texture-view exclusion is retired

MobileGL/MG_Remote/CONTRACT-P7.md

@@ -160,7 +160,7 @@ verify 今天只在 monolith 注册（`MG_IntegrationTest/CMakeLists.txt:1684-17
 - §5.4 的「白盒断言发出的是 `BufferSubDataResident(49)`」在本树**不可达**：resident 发射需要 GPU 常驻存储 → 需要 `AdoptPersistentMap` → split 下 T2 对每次采纳都 decline（`PipeApply.cpp:2331`），T0/T1 归 P11。本阶段证明到「server 按自己的表发布该位、client 镜像在双后端 × 三传输收到」为止；`rsd=` PipeStats 计数器在 P11 落地采纳档后会显示这些记录。
 - §5.3 的 `g_programResourceCaches` 删除只在 disaggregated 构建：monolith 消费者已改读归档（red-once 在 monolith 臂也红），但归档成员必须 `#if MOBILEGL_BUILD_DISAGGREGATED` 才能守 G1，pull 构建保留旧缓存——钉子挪动那天一行改完，**P13**。
 - 门 3 的「不确定」在 wave 1 E0 之前无法区分「同 case 多次结果不同」与「不同 case 各自低于阈值」；两个历史点值（0.988998 / 0.976494）无 per-case 归属。**已归属（W4，ID-P7-25）**：两个点值都是 OpenRA 同一帧里被静默丢掉的一段 draw（9836 / 14658 像素），run-ahead 与 spawn 臂都掷硬币；修复归 B3。
-- **`TextureViewAliasScenario.TheOwnerUploadDrainRunsAgainAfterADrawBoundary` 在三条 split 臂按名排除**（D2 的新门发现的产品缺陷：view 被采样过之后，owner 上的 `glTexSubImage` 再也不经 view 可见——`Managers.cpp:15433` 读 view 自己的 `record.Serial`，owner 侧 `resource_subdata` 只推 owner 的（`PipeApply.cpp:1175`），`Desc.ViewOf` 无反向索引；`CONTRACT-P5E.md:387-395` 写的就是这个洞）。主人 **D3**；落地时删排除、改 P5E §5.2 的 clean-gate 句。排除同时把它从 tier-2 Magma 回放里拿掉了（`MGL_SPLIT_ARM_CALLS` 共用过滤）。
+- ~~`TextureViewAliasScenario.TheOwnerUploadDrainRunsAgainAfterADrawBoundary` 在三条 split 臂按名排除~~ **已退（wave 2-D3，`6eaaf492`）**：split 的 clean gate 改读 storage record（`IsDrawSyncCleanByRecord` 走 `Desc.ViewOf` 到 owner，与 Magma 的 `ResolveWireTextureStorage` 同形），排除删除，三臂 3 红 → 14/14；P5E §5.2 改写。留下的：该场景的 Magma 臂只在 informational 层；`KHR-GL46.texture_view.coherency` 无 split 读数（门 5）。
 - **bsl-esc-menu-854 在 wire 臂上是内存缺陷不是排除项**（W4 §2/§3c）：monolith 807 MiB 峰值通过；spawn 下 server 进程涨到 ~1.2 GiB 在 scudo 二级分配器 `internal map failure (Out of memory)` 死（系统尚余 8 GB → 是映射数或每进程上限，不是系统 OOM），client 同时 543 MiB；inproc 1.6 GiB 也死。归属交 **M1** 调查（store 逐项归因、泄漏还是 2× 结构重复、`vm.max_map_count`）；与 B3 的「`UploadPendingWireLevels` 拒绝后 pending 条目存活」可能同根。
 - `MEASUREMENTS.md` §7.2 的同名比对自 P5b 起未重跑；「22 → texture readback」「3 → query」两行债务的关闭以 wave 3 的重跑为准。
 - Android 模拟器 retrace 车道每轮 2–6 例 flaky（含 monolith 对照）：门 1 的任何模拟器证据都先过「连续 N 轮绿」再算数。

docs/Disaggregated/notes/p7/INTEGRATOR-DECISIONS-P7.md

@@ -30,4 +30,5 @@
 | ID-P7-25 | 2026-09-22 | W4 真机复验（p7w4 = `8c5dd6fc`，`device-window-1/W4-verify/`）：iterationt ×2 通过（B 的 mip 退役兑现）；门 3 AFTER 矩阵 **34/36 与 monolith 差 ≤ 0.0005**，未过的只剩 OpenRA 与 bsl-esc-menu（inproc OOM，待 spawn 臂）。**ID-P7-19 的「冷驱动缓存」读法撤回**：16 遍显示 run-ahead 臂是与温度、`IPC_AUDIT`、`FIF=1` 都无关的每次约 50% 的竞态，且只产生两张图（`ace2af04` = golden、`fb75d412` = 14658 像素错，与 B 修复前逐字节相同）；lockstep 确定性地给第三张 `4e5ba514`（0.988998 = E1）。B 的回读 fence 修复保留（真洞）但不是本分歧的机制。**门 3 对 OpenRA 的验收改为** run-ahead 与 lockstep 各 6 遍全 `ace2af04`，冷热各半。归因交 B3（四镜头调查 + 裁判）。D2 落地时顺手：`SubsystemDepsTest` 在 pull 构建下调用 push-only 的 resolver 使 `build-linux` 编不过而 `.so` 陈旧、G1 看似恒等——门脚本改为对 `linux build rc≠0` 硬红（ID-P7-11 的第二次）。 | 16 遍的表在 `W4-verify/README.md` §3；目标调用 31249 是 `glXSwapBuffers`，快照在 swap 前经普通 `glReadPixels` 入流，present 是 class-B 记录，没有旁路。 | `W4-verify/README.md`、`CONTRACT-P7.md` §7.2、`SubsystemDepsTest.cpp`、`p7-gate-*-inner.sh` |
 | ID-P7-26 | 2026-09-22 | wave 2-D2 落地（`9d857dc0..e7c5fc60` + pull 构建修复 `6da19f71`）；fable 审查判「带修复落地」，修复 1/2/4（TUS 散点工作负载的 union box 盖满整层所以 `rect=0` 是几何不是 unpack-ring 策略——`CoversWholeLevel`；`espryt_memo_purity.py` 对改名家族 fail-open、`LEGACY_MEMOS` 默认 ON 的措辞、`FRONTEND` 无词界；普查数 71→72、+37→+76、每片 Gates 行）交 D2 返工一轮，修复 3（排除用例的契约行）由集成者记 §12。**批准** D2 触及 `MG_Pipe/*`（`SubsystemDeps.def`、`MGPipe.h` 表）与 `CONTRACT-P5.md`：在 §9 D 簇清单之外，但正是计划 R-5/R-3 行点名的文件。审查确认：产品代码零 abort/Fatal/MGLOG 新增、`MG_Backend/` 零触及、G1 恒等、`SubsystemDeps.def` 与 `PipeFill.cpp:1487-1518` / 六个 resolver 逐行一致。 | 审查报告全文在 agent 记录；要点已入本行与 §12。 | `TextureUploadShapeScenario.cpp`、`espryt_memo_purity.py`、`split-scenario-census.md`、`CONTRACT-P7.md` §12 |
 | ID-P7-27 | 2026-09-22 | bsl-esc-menu-854 **不排除**：monolith 807 MiB 通过、spawn 的 server 进程 ~1.2 GiB 死于 scudo `internal map failure`（client 543 MiB、系统余 8 GB）、inproc 1.6 GiB 死——wire 臂的内存缺陷（≈2.1× 字节或映射数上限），派 **M1** 归因（host 复测、逐 store 归因、泄漏/平台、`max_map_count`），修复包随归因定分区。 | `W4-verify/README.md` §3c 的采样表；ID-P7-12 的规则是「monolith 自己红才排除」。 | `CONTRACT-P7.md` §12 |
+| ID-P7-28 | 2026-09-22 | wave 2-D3 落地（`6eaaf492 de6fb063 25b586d0`；其 `8274dcab` 与集成者的 `6da19f71` 重复，不取）：view 陈旧缺陷取「谓词解析到 storage record」而非反向索引（删除顺序：反向索引要在 view 死亡时剪枝，否则 owner 上传会推到被回收给无关纹理的槽——静默跨纹理串号；且把可变状态放进两后端共读的 `MG_Pipe`）；删除顺序由构造保证（`TextureObjectView::m_storageOwner` 强 `SharedPtr`，`resource_destroy` 在析构发出，`TextureObject.cpp:63`）。D-K2 「两处一行」实为六处读者，全部改读 `SubsystemDeps.def`，client 侧参数按 `kMGPipeP4aFamilySubsystems` 掩码（bit 8 的 vertex-input 发射归 P3a 规则，`TextureEmit.EveryDKTwoDependencyRowGatesItsOwnFamilyAndTheMirrorPairsStayLive` 抓到）；**批准**「`SubsystemDepsTest` 从比两份副本变成比两个读者」的减弱，编译期一半（`MGPipe.h:225/:230`）承担。门：pull rc 0、`.text` 0xa52203、nm 0/0；unit 2426 / split 303 / spawn 219 / tcp 222 / magma 88/67/69 / full 530；census 79、ratchet 186、parity 0。门脚本模板自此对 `linux build rc≠0` 打 `GATE-RED`。 | `notes/p34b/espryt-d3.md`；两处基线引文更正（KHR-GL46 非 GL43；`texture_view` 1/7 红是 `view_sampling` 不是 `coherency`）。 | `Managers.{h,cpp}`、`PipeFill.cpp`、`DirectGLES.cpp`、`SubsystemDeps.def`、`CONTRACT-P5E.md` §5.2、`CONTRACT-P7.md` §12 |
 | ID-P7-19 | 2026-09-22 | OpenRA 真机分歧改判为 **wire 臂的 GPU 时序竞态**（冷驱动缓存 = 慢 pipeline 创建 → 最终帧回读在最后几批 draw 完成前采样），归 wave 2-B 第 0 片；主机 red-once 用 pipeline 创建延迟旋钮复现；真机验收 = 三次 `pm clear` 冷跑 1.0。F1 保留（机制正确）但不再被当作分歧原因。 | E7：`pm clear` 三遍 0.976493989 / 14658 逐字相同、热跑 1.0、冷 monolith 1.0、`FRAMESINFLIGHT=1` 一绿一红；两臂 client/server 日志逐行相同；diff 只缺最后画的对象。 | `WireFramebuffer.inc`、`VulkanRenderer.cpp`、`F1-verify/README.md` |