[Docs] (P12): the ring-1024 experiment - every deferred answer comes back (readfail 8,872 -> 0), so eviction was the whole cause and the residency budget is now the brake

One-line experiment before writing the retention table: StreamLink's kReplyRing 8 -> 1024,
nothing else changed, same load frame on the same device.

                       ring = 8 (today)   ring = 1024
    readfail                    8,872              0
    taken                          63          4,499 / 4,500
    blocked (fell back)         4,435              0
    by_op 2                     9,071          3,443
    wall                        27.9 s         23.04 s
    frame-sent        create 4,536, records 103,097   identical per op

TWO CONCLUSIONS. First, eviction was the ONLY cause: with a buffer deep enough, every
deferred answer was read back and not one create fell through to the blocking path.
The wedge (want=310) and the useless budget (budget=4,451) were two faces of "eight
slots is not enough". Second, what brakes now is the BUDGET, not the buffer: by_op 2 =
3,443 matches the number of times the budget forced an early read (3,395), i.e. every
one of those is a real blocking wait. Its constant is 7, sized for the 8-slot pool, so
against a 1,024-deep buffer it became the only throttle and the wall only moved 27.9 ->
23.0 s.

WHAT IT MEANS FOR THE DESIGN. Once the answers are RETAINED until read, correctness no
longer depends on how long one survives in a bounded buffer, so the budget must be
sized to the RETENTION CAPACITY rather than to the pool - or be replaced by "retained
means safe". by_op 2 = records/W then puts W=2 at ~2,268 waits and the wall at ~15 s,
which is the goal's own success criterion.

Experiment reverted (ring back to 8, probes deleted); 172 + 13 + 22 + 103 green.

docs/Disaggregated/notes/p12/CREATE-WINDOW-MEASURED.md

@@ -226,7 +226,34 @@ if (x.replySeq != seq) return ... MOBILEGL_ERR_PROTOCOL_MISMATCH;   // 等的是
 **两步都留在树里**：第 1 步是净收益；第 2 步是安全方向（只会让窗口退化成不延后＝pre-window 形状），
 而且它用的时钟 `ReplyPostings()` 正是保留方案要用的。
 
-## 10. 复算
+## 10. 第 0 步实验：把 `StreamLink` 的环从 8 放到 1024 —— 诊断确认
+
+§9 的结论是「延后要成立必须保留」。在写保留表之前先做了一个**一行实验**把这句话证死：把
+`StreamLink::kReplyRing` 从 8 改成 1024（其余一切不动），同一个负载帧：
+
+| | 环 = 8（现状） | 环 = 1024（实验） |
+|---|---|---|
+| `readfail` | 8,872 | **0** |
+| `taken` | 63 | **4,499 / 4,500** |
+| `blocked`（回退阻塞路径） | 4,435 | **0** |
+| `by_op 2` | 9,071 | **3,443** |
+| 墙钟 | 27.9 s | **23.04 s** |
+| `frame-sent` | create 4,536 / records 103,097 | 逐 op 相同 |
+
+**结论一：唯一的原因就是淘汰。** 环够深，延后的答案**每一个**都读回来了（4,499/4,500），一次都没有回退到
+阻塞路径。§8 那个 `want=310` 的楔子、§9 那个 `budget=4451` 的无效预算，都是「8 个位置不够」这一个事实的两种表现。
+
+**结论二：现在刹车的是预算，不是缓冲。** `by_op 2 = 3,443` 恰好等于 `budget` 触发次数（3,395 量级）——
+也就是**每一条被预算强制提前取回的答案，都是一次真实的阻塞等待**。预算的常数是 7（按 8 槽池定的），
+而实验里缓冲有 1024 深，于是预算变成了唯一的节流阀，墙钟只从 27.9 s 降到 23.0 s。
+
+**这对设计意味着什么**：保留表落地之后，正确性不再依赖「答案在缓冲里活多久」——**答案被持有到被读走为止**。
+于是预算不该再按 8 槽池定，而应当按**保留容量**定（或者干脆由「保留即安全」取代）。
+按 `by_op 2 ≈ records / W` 推算，W=2 时应是 ~2,268 次等待、墙钟 ~15 s——**正是 goal 里那条 15-16 s 的判据**。
+
+实验状态已还原（环回到 8、探针全部删除），四个车道 172+13+22+103 全绿。
+
+## 11. 复算
 
 ~~~sh
 # 两臂的帧读数（handoff-2 §1 的读法）