docs(notes): record hosted Session corpus timing with parallel preparation

.agents/notes/implemented/testing/2026-09-28-session-corpus-performance.i18n.yaml

@@ -21,8 +21,8 @@
   en: d9406e015ec714f3
   zh: f9cf3fbf2f0f2f7c
 /agent-note-performance-baselines-for-large-session-corpora/calibration-evidence:
-  en: f7b97edb97e672e0
-  zh: 29421fb8c3887408
+  en: 293174ed71f075d7
+  zh: 8745652547f72a66
 /agent-note-performance-baselines-for-large-session-corpora/alternatives-considered:
   en: 4eaa4666262a1aee
   zh: 7e2eb44b94bad05d

.agents/notes/implemented/testing/2026-09-28-session-corpus-performance.md

@@ -60,7 +60,7 @@ Budgets use standard two-CPU hosted CI expectations (Linux x64, Node 24.21, PR #
 | Fork: p99 | 1,522.7 / 1,485.5 ms | 1,600 ms | 2,000 ms |
 | Fork: longest (one sample) | 18,871.9 / 20,326.7 ms | 20,400 ms | 25,500 ms |
 
-With seeding in one process, the complete file took 294.5 s on the EPYC 7763 runner (85 s seeding, 26 s listing, 149 s searching, 34 s forking) and 266.6 s on the 9V74. Parallel preparation cuts local seeding from 15.1 s to 9.8 s; the process holding the longest Session finishes last. Each additional 1,000 listed Sessions costs about 9 s, so a larger list corpus would leave less than a tenth of the limit for runner variation.
+With seeding in one process, the complete file took 294.5 s on the EPYC 7763 runner (85 s seeding, 26 s listing, 149 s searching, 34 s forking) and 266.6 s on the 9V74. With parallel preparation it took 276.8 s on the 7763: the two preparation processes took 59 s and 65 s, because they share two CPUs with Zstandard and garbage-collection threads, and writing the corpora took 4.6 s. The other cases varied by less than 3% between runs on one runner model. Each additional 1,000 listed Sessions costs about 9 s, so a larger list corpus would leave less than a tenth of the limit for runner variation.
 
 On Apple M5 Pro with Node 26.5, isolated runs measured list 1,000 at 311–358 ms first, list 5,000 at 1,364–1,603 ms first, search at 57 s first, and fork of the longest Session at 6.0–6.4 s. A 10,000-Session list took 3.2–5.4 s for the first call with 1.9 GB peak RSS.
 

.agents/notes/implemented/testing/2026-09-28-session-corpus-performance.zh.md

@@ -60,7 +60,7 @@ worker 是编译后的纯 Node 进程，每次都针对已播种根目录全新
 | Fork：p99 | 1,522.7 / 1,485.5 ms | 1,600 ms | 2,000 ms |
 | Fork：最长（一个样本） | 18,871.9 / 20,326.7 ms | 20,400 ms | 25,500 ms |
 
-单进程播种时，整个文件在 EPYC 7763 运行器上耗时 294.5 s（播种 85 s，列表 26 s，搜索 149 s，fork 34 s），在 9V74 上耗时 266.6 s。并行准备把本地播种从 15.1 s 缩短到 9.8 s；持有最长 Session 的进程最后完成。列表语料每增加 1,000 个 Session 约多花 9 s，因此更大的列表语料会让留给运行器差异的时间不足上限的十分之一。
+单进程播种时，整个文件在 EPYC 7763 运行器上耗时 294.5 s（播种 85 s，列表 26 s，搜索 149 s，fork 34 s），在 9V74 上耗时 266.6 s。并行准备后，它在 7763 上耗时 276.8 s：两个准备进程分别耗时 59 s 和 65 s，因为它们与 Zstandard 和垃圾回收线程共享两个 CPU；写入语料耗时 4.6 s。其他用例在同一运行器型号的多次运行之间差异小于 3%。列表语料每增加 1,000 个 Session 约多花 9 s，因此更大的列表语料会让留给运行器差异的时间不足上限的十分之一。
 
 在 Apple M5 Pro 和 Node 26.5 上的隔离运行中，1,000 个 Session 的首次列表为 311–358 ms，5,000 个 Session 的首次列表为 1,364–1,603 ms，首次搜索为 57 s，fork 最长 Session 为 6.0–6.4 s。10,000 个 Session 的首次列表耗时 3.2–5.4 s，峰值 RSS 为 1.9 GB。