docs(embedding,memory): 复核 p2 的三处措辞改正（纯注释，零行为改动）

review-m15 round1 判 p2-1items（fix-then-merge），三条都属「把证据能支撑什么写准」：

1. api.go 原写「最坏也只是这一片失败」与实现语义**相反** —— Embed 的实际语义是
   「任一片失败 ⇒ 整条调用失败、其余分片已算完的工作量一并丢弃」。改为与该包
   budget.go 里已经写对的那一句对齐，并点明调用方据此降级（记忆一条不丢、判定规则
   一字不改，变的是这一条审查的召回质量）。
2. 「尖峰与批次无关」是**过度断言**：原证据只支持「至少存在一个与批次无关的外部/
   争用分量」（4 条/片也实测到 7.139s）；越界的**频率**是否随批次上升，1/40 vs 2/40
   的样本不足以判定 ⇒ 改标为「归因未定」，并明说批上限取 8 的依据始终是硬证据
   （16 条/片实测越界 + 真实代码路径 3 次里 2 次越界），**不依赖**任何成因推断
   （原文与同文件「16 条越界故不取更大」的理由自相矛盾）。同时补上独立复核窗口的
   对照（review-m15：24 次单请求 0 尖峰）说明尖峰强依赖窗口负载。
3. budget.go 的不变式不再被读成延迟保证：明确定性为「**稳态、空闲机器的建模拟合**，
   用途是构造批形状」，并点名真正的兜底（90s 审查预算按整条链算 + 任一片失败即降级
   的路径 + 已登记的链路韧性遗留）；结论句由「8 条/片不越界」改为「**空闲实测下**不
   越界、负载下仍偶发越界」；perItemBudget 与 callBudgetShare 注释里「另一半／余量」
   的同口径措辞一并改正（加一句：这是建模余量，不是单请求一定不越界的保证）。

另：preinsert_config.go 里「设计稿那一行待同步」已过期 —— 塔同日已把 design/23 §15
同步为 Timeout=90s，改为「已按实测同步」。

验证：go build ./... / go vet ./... 干净；go test -count=1 ./... 全绿；
go test -race -count=1 ./internal/runtime/embedding/... ./internal/runtime/memory/...
全绿；diff 中无非注释行（纯文档改动）。

internal/runtime/memory/preinsert_config.go

@@ -49,8 +49,8 @@ const (
 	//   - 审查超时后的失败形态目前**不写留痕**（preinsert.go 的 `ctx.Err()` 分支，
 	//     不属本次改动范围）⇒ 预算越长，「静默停摆」的窗口越长、面板越看不出来。
 	//
-	// 🔴 与设计稿的差异（如实登记）：design/23 §15 那一行写的是 `Timeout=20s`，
-	// 是本次改动**之前**的口径；本值按上面实测抬高，设计稿那一行待同步。
+	// 🔴 与设计稿的对齐（如实登记）：design/23 §15 那一行原写 `Timeout=20s`（本次改动
+	// **之前**的口径），已按上面实测同步为 `Timeout=90s`。
 	defaultReviewTimeout = 90 * time.Second
 	// reviewAuditWho / reviewAuditVerb 是审查留痕的审计口径：它是**系统任务**，
 	// 不是任何角色（design §4.1 C 的同一理由）。