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/embedding/api.go

@@ -45,9 +45,11 @@ const (
 // 为什么每次调用必须有自己的上限：上层「入库前审查」的单条总预算是 90s
 // （memory.defaultReviewTimeout），而**一条召回链是几十个请求**（201 条 ÷ 8 条/片
 // = 26 个，见 budget.go 文件头的链路实测）—— 一次卡死的 HTTP 不能把整条审查的预算
-// 都赌掉：把它压在 5s，最坏也只是这一片失败，调用方按**既有语义**降级（审查降级到
-// 词项余弦并如实留痕 degraded），**绝不静默丢记忆**。本常量只砍等待时间，不改任何
-// 判定规则。
+// 都赌掉：把它压在 5s，最坏是**这一片超时**；而 `Embed` 的语义是**任一片失败 ⇒
+// 整条调用失败**（其余分片已经算完的工作量一并丢弃），调用方据此按**既有语义**降级
+// （召回降级到词项余弦并如实留痕 degraded）——**记忆一条不丢、判定规则一字不改**，
+// 变的是这一条审查的召回质量。本常量只砍等待时间，不改任何判定规则。
+// （同一口径见 budget.go 文件头 ④ 末段。）
 //
 // 5s 保持不变的依据：本次故障（2026-10-13）的成因**不是**这个数太小（链条是
 // 「N 条 → ⌈N/批次⌉ 个请求」，链长超的是**调用方**预算），因此修法是把链条收短
@@ -55,11 +57,12 @@ const (
 // 20s → 90s），而不是把单次超时放大到迁就链条 —— 后者会让真挂死的请求也一起
 // 拖住整轮审查。
 //
-// ⚠️ 已知残余（见 budget.go 文件头 ④）：空闲窗口实测单请求最大 1.782s，但**任何**
-// 批次形状都偶发越过本超时的尖峰（实测 4 条 7.139s、8 条 9.711s —— 明确与批次无关）。
-// 越过它的后果被设计成**有界的**：那一次调用失败 ⇒ 调用方按既有语义降级
-// （召回回落词项余弦 + 留痕 degraded），**不是**整轮丢失。真正要治的是链路对单点
-// 慢分片的韧性（重试/分片级容错），不在这里。
+// ⚠️ 已知残余（见 budget.go 文件头 ④）：空闲窗口实测单请求最大 1.782s，但尖峰会越过
+// 本超时 —— **至少存在一个与批次无关的外部/争用分量**（实测 4 条/片也能到 7.139s）；
+// 越界的**频率**是否随批次上升，本组样本（1/40 vs 2/40）不足以判定，**归因未定**。
+// 后果：那一片超时 ⇒ **整条 `Embed` 失败**、其余分片已算完的工作量丢弃 ⇒ 调用方按
+// 既有语义降级（召回回落词项余弦 + 留痕 degraded）—— 记忆不丢、判定规则不改。
+// 真正要治的是链路对单点慢分片的韧性（重试/分片级容错），不在这里。
 //
 // 冷启动另有 warmupTimeout（见 budget.go），但它**只放宽本进程的第一个请求**、
 // 且一次性花掉：失败不会让它续期，因此「服务一直挂死」这件事**不会**变成