docs(memory): 请求上界按条数维+字符维两维算准（review-m61 P2-1）

embedding.Embed 同时受条数界（8）与字符界（480 字）约束 ⇒ 一次 embedOnce(B 条)
会发 C 个请求（C 由正文长度决定，1..B），因此：

  正常批            C
  含一条坏正文      ≤ C + B（短正文 9；均长 75 汉字的现实批 10；病理上限 2B=16）
  服务整体挂死      首个 chunk 即失败 + 逐条 B ⇒ 1 + B = 9（与字符维无关）

修正 embed_isolation.go 文件头的上界表、approxRequests 的「两者一致」表述、
embedReuseStats.Sent 的注释，以及 embed_resilience_test.go 的上界注释与日志文案。
零行为改动：判据、实现、请求数都未动，测试全绿。

internal/runtime/memory/embed_incremental.go

@@ -51,7 +51,8 @@ type embedReuseStats struct {
 	Requested int
 	// Reused 是索引里已有向量、一次远端都没发的条目数。
 	Reused int
-	// Sent 是真正送进 embedder 的**条数**（≈ 请求数 × 批上限）。
+	// Sent 是真正送进 embedder 的**条数**；HTTP 请求数 ≥ ⌈Sent/批上限⌉ ——
+	// embedding 包还会按字符界（480 字）再切，长正文时请求数更多（见 approxRequests）。
 	Sent int
 	// Dropped 是逐条隔离重试后仍失败、本轮没有向量的条目数（缺口）。
 	Dropped int
@@ -62,8 +63,10 @@ type embedReuseStats struct {
 }
 
 // approxRequests 估算本轮发出的 HTTP 请求数：条数 ÷ 批上限（向上取整）。
-// 它是**观测用的估算**（embedding 包内部还按同一个批上限切片，因此两者一致），
-// 不是任何判据。
+//
+// 🔴 它是**按条数界算的下限估算**，不是精确值：embedding.Embed 还按字符界
+// （DefaultBatchChars=480）切片，长正文批会被多切一刀 ⇒ 真实请求数 ≥ 本估算
+// （短正文、≤480 字/批时两者相等）。它只进日志做观测，不是任何判据。
 func (s embedReuseStats) approxRequests(batch int) int {
 	if s.Sent <= 0 {
 		return 0